Hello,
In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
that a page would be skipped if it is "active". For example, I have
currently modified 2.4.13-pre2 by adding:
if (PageActive(page))
return 0;
after testing the hardware referenced bit. This was motivated by
sections of VM-improvement patches written by both Rik and Andrea.
This SEEMS to increase performance, but it has another side effect. The
RSS of unused daemons no longer EVER drops to 4k, which it does without
this modification. The RSS does decrease (usually) to the value of
shared memory, but the amount of shared memory only gets down to about
200-300k instead of decreasing to 4k.
Can anyone tell me why not scanning Active page for swapout would have
this effect? Thanks!
-BenRI
--
"I will begin again" - U2, 'New Year's Day'
Benjamin Redelings I <>< http://www.bol.ucla.edu/~bredelin/
> In both Andrea and Rik's VM, I have tried modifying try_to_swap_out so
>that a page would be skipped if it is "active". For example, I have
>currently modified 2.4.13-pre2 by adding:
>
> if (PageActive(page))
> return 0;
>
>after testing the hardware referenced bit. This was motivated by
>sections of VM-improvement patches written by both Rik and Andrea.
> This SEEMS to increase performance, but it has another side
>effect. The
>RSS of unused daemons no longer EVER drops to 4k, which it does without
>this modification. The RSS does decrease (usually) to the value of
>shared memory, but the amount of shared memory only gets down to about
>200-300k instead of decreasing to 4k.
> Can anyone tell me why not scanning Active page for swapout would have
>this effect? Thanks!
The "active" pages in your inactive daemons are probably the glibc
pages, which are generally in use by other applications. It should
not have any real effect on the system - in fact, keeping glibc in
memory is probably a Good Thing, and may be partially responsible for
your improvement in performance.
AFAICT, 'pinning' active pages in memory is a good thing, provided
they are deactivated appropriately after a period of disuse. This
appears to be the case in current kernels and the new VM, so you're
good to go in my view.
--
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected] (not for attachments)
website: http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline: The key to knowledge is not to rely on people to teach you it.