Some VM tweaks (against 2.4.5)

Some VM tweaks (against 2.4.5)

[Jonathan Morton]

I've made a collection of small tweaks to the 2.4.5 VM which "work for me",
and hopefully are largely applicable to other workloads as well.

http://www.chromatix.uklinux.net/linux-patches/vm-update-1.patch

Summary (roughly in order as found in the patchfile):

- Increased PAGE_AGE_MAX and PAGE_AGE_START to help newly-created and
frequently-accessed pages remain in physical RAM.

- Includes my tweak to vm_enough_memory(), to limit memory reservation
under low-memory conditions (this isn't quite working as expected, but
seems to be harmless).

- Fixes out_of_memory() to use the same (and more correct) criteria as
vm_enough_memory().  Does NOT include my revised OOM-killer algorithm,
although it is probably sorely needed.

- Changed age_page_down() and family to use a decrement instead of divide
(gives frequently-accessed pages a longer lease of life).

- In try_to_swap_out(), take page->age into account and age it down rather
than swapping it out immediately.

- In swap_out_mm(), don't allow large processes to force out processes
which have smaller RSS than them.  kswapd can still cause any process to be
paged out.  This replaces my earlier "enforce minimum RSS" hack.

- Bump up the page->age to PAGE_AGE_START when moving a page to the active
list in page_launder().

- Includes Zlatko Calusic's patch from earlier today, since I can't see
anything immediately wrong about it.

Please go ahead and test, and (constructively) criticise.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S 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+(*)
-----END GEEK CODE BLOCK-----


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Some VM tweaks (against 2.4.5)

[Stephen C. Tweedie]

Hi,

On Sun, Jun 03, 2001 at 03:06:22AM +0100, Jonathan Morton wrote:

> - Increased PAGE_AGE_MAX and PAGE_AGE_START to help newly-created and
> frequently-accessed pages remain in physical RAM.
 
> - Changed age_page_down() and family to use a decrement instead of divide
> (gives frequently-accessed pages a longer lease of life).

We've tried this and the main problem is that something like "grep
foo /usr/bin/*" causes a whole pile of filesystem data to be
maintained in cache for a long time because it is so recent.  Reducing
the initial age of new pages is essential if you want to allow
read-once data to get flushed out again quickly.

> - In try_to_swap_out(), take page->age into account and age it down rather
> than swapping it out immediately.

Bad for shared pages if you have got some tasks still referencing a
page and other tasks which are pretty much idle.  The point of
ignoring the age is that sleeping tasks can get their working set
paged out even if they use library pages which are still in use by
other processes.  That way, if the only active user of a page dies, we
can reclaim the pages without having to wade through the working set
of every other sleeping task which might ever have used the same
shared library.

> - In swap_out_mm(), don't allow large processes to force out processes
> which have smaller RSS than them.  kswapd can still cause any process to be
> paged out.  This replaces my earlier "enforce minimum RSS" hack.

Good idea.  I'd be interested in seeing the effect of this measured in
isolation.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Some VM tweaks (against 2.4.5)

[Jonathan Morton]

>> - Increased PAGE_AGE_MAX and PAGE_AGE_START to help newly-created and
>> frequently-accessed pages remain in physical RAM.
>
>> - Changed age_page_down() and family to use a decrement instead of divide
>> (gives frequently-accessed pages a longer lease of life).
>
>We've tried this and the main problem is that something like "grep
>foo /usr/bin/*" causes a whole pile of filesystem data to be
>maintained in cache for a long time because it is so recent.  Reducing
>the initial age of new pages is essential if you want to allow
>read-once data to get flushed out again quickly.

Noted.  But what about pages which already "exist" but are freshly swapped
in?  Maybe we should indeed have a low PAGE_AGE_START, but push page->age
to PAGE_AGE_MAX when it is swapped in by a major fault.  I assume, of
course, that the act of reading data from a file is not handled by means of
a major fault...

>> - In try_to_swap_out(), take page->age into account and age it down rather
>> than swapping it out immediately.
>
>Bad for shared pages if you have got some tasks still referencing a
>page and other tasks which are pretty much idle.  The point of
>ignoring the age is that sleeping tasks can get their working set
>paged out even if they use library pages which are still in use by
>other processes.  That way, if the only active user of a page dies, we
>can reclaim the pages without having to wade through the working set
>of every other sleeping task which might ever have used the same
>shared library.

I'm not sure I agree with your logic here, but I'll think on it, perhaps
out loud.  First of all, the working set is not calculated per se at
present.  Instead, we attempt to make the resident set roughly match the
working set by some (crude) algorithms.  With this in mind, it doesn't
matter a jot if there are multiple (active or not) users of a given page,
since the page is only resident once.  When all processes have stopped
actively using it, the age of that page will decrease and it will be paged
out if needed.

>> - In swap_out_mm(), don't allow large processes to force out processes
>> which have smaller RSS than them.  kswapd can still cause any process to be
>> paged out.  This replaces my earlier "enforce minimum RSS" hack.
>
>Good idea.  I'd be interested in seeing the effect of this measured in
>isolation.

Time for the big boys to get out their toys again.  :)  I did some testing
by compiling MySQL on my Athlon with mem=32M, which is what led me to
realise that the "enforce minimum RSS" could actually decrease overall
throughput dramatically, even if processes weren't actually using the
(artificially) reserved memory.  This test also emphasises rather nicely
the difference between "heavy paging" and "thrashing" - given just the few
extra Mb of RAM, most of the C++ compiles went to "heavy paging" mode and
made rapid progress.  The "monster" C++ file was the only one left
thrashing when the "anti-big-bully" patch was applied.  I haven't directly
compared the anti-big-bully patch to the stock kernel, though.

As a side note, let me point out that XFree86 has a large RSS, much of
which is not part of the normal memory map (it is VRAM).  Therefore XFree86
suffers unduly at the hands of the anti-big-bully patch, and has more
difficulty paging bits of itself in when it needs to.  This could
potentially be true of other classes of application, too.  It does still
seem to soldier on bravely, though, so kswapd is doing it's job.

I'd like to see the swapping-out routines schedule more often.  The
rationale for this is to allow small processes to maintain their access
pattern while the ageing process grinds on, and also to dissipate the "big
bag o' lag" as a big swap-out operation takes place.  I've seen small,
continuous processes (mpg123, dnetc, xosview) losing several seconds of
access to the CPU as another process ate up memory and caused a large
swap-out.  Can someone suggest a good place to do this, and advise on the
proper sequence of events?

I'm also still left with the decided view that a proper working-set
calculation would be the best overall solution.  On an otherwise-idle
system, I want that C++ process to take over as much as possible -
including most of the buffers+cache space - so it makes maximum progress.
At present this is partially handled as the end result of some mysterious
interactions, and IMVHO needs to be made more explicit.  If made more
explicit "hmm, in this section of code we decide how much memory we're
going to give process X", tuning could become that much easier...

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S 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+(*)
-----END GEEK CODE BLOCK-----


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/