To join in the discussion, let me point out that as part of google
summer of code 2006, we initiated a project (mentor: Bill  Studenmund)
to implement congestion control inside the uvm so that in the presence
of multiple readers and writers, disk access gets skewed towards the
readers process.

The algo works well till the number of free pages drops to a ciritical
low level and the page daemon gets fired. This causes the reader
processes to stall since there are no pages to read in the data.. The
degradation in performance (when the pdaemon gets fired) was observed
to --indepedent-- of the bufq strategy (prioscan, scan, cscan)..
Hence, it is not surprising that  BUFQ_PRIOCSCAN does not work as
pointed out.

Since we have  indications that the dynamics of the pdaemon needs to
be investigated, we are currently trying to understand the process of
page getting dirtied and treat them as important events in our
framework. Currently, the work is in the prelim stages; updates will
be posted as and when available.

Thanks,
Sumantra

This observation

On 9/20/06, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
> > tls@rek.tjls.com wrote:
> >
> > > On Wed, Sep 20, 2006 at 07:17:43PM +0900, YAMAMOTO Takashi wrote:
> > > > > Maybe the author (yamt) can explain us why is it marked experimental?
> > > >
> > > > i can't remember why. :)
> > >
> > > I thought I remembered that you said it didn't work right because the
> > > VM system didn't distinguish between pages that were dirty for different
> > > reasons.  I do not remember the details!
> >
> > Mentioned in this post?
> > http://mail-index.NetBSD.org/tech-kern/2005/06/09/0001.html
> >
> > Or UVM has been improved enough in these days?
>
> no, but it is a more generic problem than BUFQ_PRIOCSCAN, IMO.
>
> YAMAMOTO Takashi
>