I have made considerable changes to the congestion control (CC)
algorithm. It can be considered version 2 (version 1 being CC inside
UVM alone).

In version 2, the CC algorithm resides inside the IO scheduler. It
monitors the dynamics of the two queues: read and write; only when it
thinks that the write queue is being filled at a rate that might
indicate congestion,  it nails down the process that has initiated
most of the write request in the queue and puts it to sleep.  That way
we concern ourselves only with IO bound processes.

Looking into the future: there will be a version 3 and version 4.
version 3 will link UVM and IO dynamics and version 4 will initiate
process admission control inside the UVM based on page daemon
dynamics.

Thanks,
--Sumantra



On 12/1/06, Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> On Mon, Aug 21, 2006 at 02:15:07PM -0700, Jason Thorpe wrote:
> >
> > On Aug 21, 2006, at 12:47 PM, Thor Lancelot Simon wrote:
> >
> > >I guess I'm confused.  How, exactly, do we measure the maximum
> > >aggregate
> > >operations/sec throughput of the disk?  There should be no upper bound
> > >on the write throughput unless we reach that number, because writers
> > >should never be put to sleep.  Is that not the case?
> >
> > There's another reason to implement congestion control, as posited by
> > Bill Sommerfeld some years ago on this list.. and that is to ensure
> > that pages are dirtied (by writing to files) no faster than they can
> > be cleaned (more or less -- obviously, there is a little more too it
> > than that :-)
>
> Isn't that exactly what I'm asking about?  "Congestion control" that
> puts processes to sleep in a way that is *unrelated* to the ability of
> the underlying disk to clear writes seems completely insane.
>
> Thor
>