Jason R Thorpe wrote:

> On Fri, Jan 26, 2001 at 11:33:02PM +0100, Johan Danielsson wrote:
>
>  > After about 3 minutes of testing, I can say that my machine feels much
>  > more responsive when compiling, I guess that's what you expected. I'll
>  > run with this for a while and see what happens.
>
> Yah, I expected improvement.  Good to know that it's working okay for
> you so far.
>
> --
>         -- Jason R. Thorpe <thorpej@zembu.com>

Yes it is an improvment, but I am still doubting that doing

                if (inactive_shortage > 0 &&
                    pmap_clear_reference(p) == FALSE) {
                        /* no need to check wire_count as pg is "active" */
                        uvm_pagedeactivate(p);
                        uvmexp.pddeact++;
                        inactive_shortage--;
                }
is the right way as referenced pages will stay on the active queue and other
pages around them (not referenced) will be deactivated this meens that this
shortly referenced pages will be scanned quiet early on the next invocation
of the scanner. If they were deactivated after clearing the referecebit it
would the page could be referenced on the inactive queue (thanks to your
patch) and would come back to the end of the active queue

code:
                if (inactive_shortage > 0) {
                        pmap_clear_reference(p);
                        /* no need to check wire_count as pg is "active" */
                        uvm_pagedeactivate(p);
                        uvmexp.pddeact++;
                        inactive_shortage--;
                }

this would result in what a two-hand-clock-pagescanner does.

Moving referenced pages found on the active queue to the end of that queue
(makeing a different of vnode and other pages) result in a change of the
first clock hand to:

referenced page -> put page behind second hand and clean reference

not referenced page -> deactivate
   (in words of the two-hand-scanner: leave for the second hand in our case
inactive queue)

this gives the scanner the opportunity to make a difference between
vnode-cache pages and "other memory"
The patch I posted yesterday improved the situation even much more keeping
the cache at a moderate size while giving it the possibility to grow in
favor of "long time not used memory" (twice the scantime of the active
queue)

lars