Re: 2.6.0-test9 - poor swap performance on low end machines

[Andrew Morton <akpm@osdl.org>]

Andrea Arcangeli <andrea@suse.de> wrote:
>
> The reason 2.4 runs faster could be a more aggressive "young" pagetable
> heuristic via the swap_out clock algorithm. as soon as one program grows
> a bit its rss, it will run for longer, and the longer it runs the more
> pages it marks "young" during a clock scan, and the more pages it marks
> young the bigger it will grow. This keeps going until it's the by far
> biggest task and takes almost all available cpu. This is optimal for
> performance, but not optimal for fariness.

Sounds right.

One thing to be cautious of here is an interaction with the "human factor".
 One tends to adjust the test case so that it takes a reasonable amount of
time.  So the process is:

Run 1: took five seconds.

       "hmm, it didn't swap at all.  I'll use some more threads"

Run 2: takes 4 hours.

       "man, that sucked.  I'll use a few less threads"

Run 3: takes ten minutes.

       "ah, that's nice.  I'll use that many threads from now on".

Problem is, you have now carefully placed your test point right on the
point of a sharp knee in a big curve.  So small changes in input conditions
cause large changes in runtime.   At least, that's what I do ;)

> So 2.6 may be better or worse
> depending if fariness payoffs or not, obviously in qsbench it doesn't
> since it's not even measured.

It would be nice, but I've yet to find a workload in which 2.6 pageout
decisively wins.

It could well be that something is simply misbehaving in there and that we
can pull back significant benefits with some inspired tweaking rather than
with radical changes.  Certainly some of Roger's measurements indicate that
this is the case, although I worry that he may have tuned himself onto the
knee of the curve.