Chuck Silvers wrote:

> On Tue, Apr 03, 2001 at 08:23:01PM +0200, Lars Heidieker wrote:
> > For me it would look right to make vnode pages that are not mapped by any
> > process inactive.
> > This would allow the fs cache to grow to approx 1/3 of main mem and it
> > would be able to use even more memory if it is free.
>
> this is basically what eduardo proposed, and the problem with that is that
> the other 2/3 of memory will more-or-less always contain anon data for
> user processes (such as our favorite application, netscape).  so we
> wouldn't be able to use any of that memory for caching file data
> *no matter how long the process is idle*.  the process could sleep
> for *years* and we would never page it out.
>
> perhaps what we need is some more gradual shifting of pages from one
> use to the other.  the current scheme will convert pages from one use
> to another (up to the limits) as fast as it can, maybe slowing that
> down would be better.
>

True limiting the cache to 1/3 is still suboptimal, another thought might be,
to flush only a limited amount of "dirty pages" on the inactive queue and
after that scanning for vnode pages that with a vnode that has use count of 1
(that vnode should not be mapped by a process and therefor "simply" fs cache)
But I am not sure that the vnode use count works allways like this...

>
> > Merging the two inactive queues improves the paging behaviour, I have
> > treied that anon and vnode pages get paged much more smoothly....
>
> hmm, I can see how the dual-inactive queue scheme might have some
> odd behaviour, yea.  do you have any numbers on how the current scheme
> behaves in a real system?  maybe you could post a diff that implements
> the merged inactive queue so that people could try it out?
>
> -Chuck

The trouble with the two inactive queues is one that shows up on higher scann
rates (that came to the system with ubc) as the current implementation scans
one of both queues until the inactive target is reached. If the vnode queue is
very long compared to the anon one the anon one will be forced to be nearly
allways empty by high scan rates.

A patch for the merged queues will be available shortly....

lars