nice vmm test case

nice vmm test case

[Roman Zippel]

Hi,

I have a simple test case that is a nice example of bad mm perfomance
under load (I tested 2.2.16 and 2.4.0-test2, it makes no big
difference). I simply edit a large file with vi (25MB file on a 64MB
system) and watch the some vmm values in top. As a simple edit operation
I remove the first character of every line (or just type ":%s,^.,,").
The interesting point is when the virtual size of vi reaches the amount
of available memory, the perfomance drops immediatly and the system is
only busy with swapping. It's interesting to watch the SWAP and RSS
numbers, they constantly jump between 0 and 50MB.
This example also shows nicely which effect it has on interactive tasks,
if you watch the numbers of top itself (I changed the update delay to 1s
and sorted it by age, so it's easier to follow), top is also busy with
keeping it's own few pages in memory (under 2.4 top generates more page
faults than vi).
The right answer would be probably page aging, but I doubt to see that
in 2.4. Anyway, the swap_cnt in vmscan.c looks suspicious, maybe it's
initiliazed too high?

bye, Roman
--
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.eu.org/Linux-MM/

Re: nice vmm test case

[Benjamin Redelings]

> Anyway, the swap_cnt in vmscan.c looks suspicious, maybe it's
> initiliazed too high?

The swap_cnt in vmscan.c is almost meaningless.  It is basically the
number of pages in a process that have not been scanned in the current
iteration. (where one iteration means that we scan all processes).

However, as (I think) John Fremlin has pointed out, sorting processes to
swap by this value is pointless.  

vmscan.c goes through all the pages (at least on my machine) pretty
fast, and that not all pages are found on the first iteration. If that
were NOT the case we would be in BIG trouble, because it would never
scan small processes until all the big ones had been scanned.  Also,
swap_cnt is not update when the RSS changes...
	This indicates that John's patch should be worth trying out...

We are eagerly awaiting patches for active/inactive lists :) :)

-BenRI
P.S. Please correct me if I'm wrong...
--
"For nature does not give virtue,
 It is an art to become good." - Seneca
Benjamin Redelings I      <><     http://www.bol.ucla.edu/~bredelin
--
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.eu.org/Linux-MM/

Re: nice vmm test case

[Roman Zippel]

Hi,

> vmscan.c goes through all the pages (at least on my machine) pretty
> fast, and that not all pages are found on the first iteration. If that
> were NOT the case we would be in BIG trouble, because it would never
> scan small processes until all the big ones had been scanned.  Also,
> swap_cnt is not update when the RSS changes...

I'm not talking about the scanning speed. What I'm seeing is that vi
continuously touches it pages, but as soon as _some_ pages are needed,
_all_ pages are swapped out. An operation that took a few minutes
before, takes now several hours (hmm, maybe days... the test that I
started on 2.2 yesterday still isn't finished :( ).

bye, Roman
--
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.eu.org/Linux-MM/

Re: nice vmm test case

[John Fremlin]

Benjamin Redelings <bredelin@ucla.edu> writes:

> > Anyway, the swap_cnt in vmscan.c looks suspicious, maybe it's
> > initiliazed too high?

Perhaps, but I think the cause of the problem might well the priority
argument to the swap_out function. For me, it is always set to around
62, so that the swap out loop is executed a ridiculous number of
times, i.e. until all memory that can be is swapped out (which seems
to be the behaviour described). You might like to force the counter to
a sensible number (say 100) by editing the source. If you're not
confortable with that, I can try to run off my current patch. (I'm not
sure if I posted it or not).

[...]

-- 

	http://web.onetel.net.uk/~elephant/john
--
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.eu.org/Linux-MM/

Re: nice vmm test case

[Roman Zippel]

Hi,

John Fremlin wrote:

> Perhaps, but I think the cause of the problem might well the priority
> argument to the swap_out function. For me, it is always set to around
> 62, so that the swap out loop is executed a ridiculous number of
> times, i.e. until all memory that can be is swapped out (which seems
> to be the behaviour described).

Hmm, for me it looks like that even in a single loop too much is done. A
single loop already tries to put as much as possible into the swap
cache. Two calls of swap_out_mm for the same mm in very short time and
most of the process is on swap and it will only be busy to get it pages
back.

bye, Roman
--
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.eu.org/Linux-MM/