&

NetBSD-SoC: A Framework For Enforcing QoS Inside the NetBSD UVM

For latest updates, please visit: http://crewman.uta.edu/~skundu/gsoc_2007.html

What is it?

For delay sensitive systems such as streaming multimedia servers and back-end database systems, servicing the reader processes in a timely fashion is more important than the servicing the writers. This is because applications are blocked from processing unless the data is made available to them by the underlying operating system (OS). Thus, readers need to be serviced instaneously while it does no harm for the writers to wait for a certain amount of time.

However, in commodity a OS such as NetBSD, there occurs no way of enforcing such process prioritization. While it is possible to prioritize the read requests at the IO scheduler level, such approaches are of little or no relevance if the virtual memory (VM) is unable to allocate free pages for the data to be read in.

In this project, we aim to prioritize the readers over the writers so that the transcations-per-second (TPS) of latency senisitve processes can be improved when the system is either experiencing lots of page requests and/or flurry of write activities.  We are currently aiming for two modular approaches: (i) Change the manner in which the pagedaemon removes pages, and (ii) provide feedback about the performance of the I/O queues to the UVM.

Status

!!! Work in Progress !!!

• May 28 2007: Students begin coding for their GSoC projects; Google begins issuing initial student payments
• July 9 2007: Students upload code to code.google.com/hosting; mentors begin mid-term evaluations
• July 16 2007: Mid-term evaluation deadline; Google begins issuing mid-term student payments
• August 20 2007: Students upload code to code.google.com/hosting; mentors begin final evaluations; students begin final program evaluations
• August 31 2007: Final evaluation deadline; Google begins issuing student and mentoring organization payments

Deliverables

Mandatory (must-have) components:

• Algorithm for measuring the performance of read/write queues in RPRIO I/O Scheduler. [Eval I]
• Understanding the impact of process count vs. {average lifetime of a page, average size of active/inactive/wired page lists, pdaemon firing intervals, I/O transactions, I/O queue size, Avg. waiting time of a request} [Eval I]
• In the current approach, the read burst size is adhoc. We would like to associate a cost of the write requests. Whenever the cost execeeds a certain prob threshold, then and only then start servicing the writers. [Eval I/II]
•  A Probabilistic Framework for the page removal process. This would ensure that the pagedaemon gets fired to ensure that the blocking probability of a page request is very low. Not on hard threhold limits. [Eval II]
• Slow down writer processes when the UVM thinks that consumption of pages by the writer processes are more than the readers. [Eval II]

Optional (would-be-nice) components:

• Show in reallife scenario that our approach really works. For example, set up Darwin Streaming Server (DSS) on the NetBSD machine with mySQL running in the background for retrieving client profile. Now if our approach works then the read TPS should not drop with increase in number of clients accessing the server.

Documentation

Technical Details

Sumantra R. Kundu <sumantra@gmail.com> $Id: index.html,v 1.3 2007/06/15 03:59:39 sumantra_kundu Exp $