Subject: Re: Throttling IO Requests in NetBSD via Congestion Control
To: None <email@example.com>
From: Sumantra Kundu <firstname.lastname@example.org>
Date: 12/02/2006 13:59:29
> That's great news. How does it decide what rate might indicate congestion?
> Where does it do this, and what mechanism does it use to block
> offending processes?
Here is my approach. We have two queues: read queue and write queue.
The preferred mechanism available today, to provide preference to
reads, is using the RPRIO scheduler. What is basically does is service
'r' number of reads before going back to service the write queue. But
what is this 'r'? we don't know.
That's where my new stochastic readprio (SPRIO) comes into the
picture. It monitors the dynamics of two queues. An important point to
note is that the average occupancy of the queue length is not a good
indication of congestion since I have observed that the arrival
process of read/write requests have considerable variance
(self-similar, autocorrelation factor). So, the algorithm calculates
the effective bandwidth (EB) of the write queue. Given a given queue
size, using EB we can tell what is the prob that the write queue will
"overflow" (i.e. cross the buffer mark). This gives us the value of
"r". Thus, the value of r is linked to the desired QoS.
Once the write queue is marked to be serviced, we note the number of
requests from each process. By keeping history, we find out how much
service time, each process has been provided. If a single process or a
handlful of processes are taking most of the service, we make them
As a caveat, it should be noted that this approach does not take care
of the situation when the pages are scare in the UVM. This would be
our next step. Apply process admission control (PAC) inside the UVM
followed by linking the intelligence of PAC with the IO scheduler so
as to exactly know which processes are rogue process.