Below is a short report about the way I feel your VM20 patch is acting on my
system. It is certainly better than stock pre7 (and pre7-ac4), but it is
still far worse than anything I had before.
In pre7, the cache is crazy. It grows, and grows, and grows, almost any time.
On my machine, a 16mb machine, I remind you, it isn't uncommon for me to
find it filling 8mb of precious RAM, while swapping out things that I
constantly work with (my mail client, while reading mail - this forces a
swap-in whenever I move to the next message. X, while using it, and so on).
In your VM20, with /cat/proc/vm/pager of '3 2 4 32 128 512', it is more
reasonable - the cache doesn't grow all the time, but it still grows when
there is a lot of i/o. A few hours ago, I had the swap fighting with the
cache while starting Netscape and my mail client at the same time, which was
foolish. vmstat shown countless swap-ins and swap-outs, while the cache kept
growing. The machine was practically not usable at that stage.
Personally, I don't like the way the pager works. It is too magical. Change
'priority', and it might work better. Why? Because. I much preferred the old
approach, of being able to simply tell the cache (and buffers, though I
don't see this unless I explicitly try to enlarge it) to *never*, *ever* grow
over some arbitrary limit. This is far better for smaller machines, at
least as far as I can currently see.
Isn't it possible to keep your changes, which seem to improve things with
other people's machines (and probably with mine too, as soon as I can make
sure I have enough RAM to do things reasonably), and yet add the hard
limit on the sizes? You would agree with me that a 6.5mb cache in a 16mb
machine (while there are about 12mb swapped, about two thirds of which are
active tasks) - isn't right.
The limit shouldn't be hard if there is free RAM - let the cache grow, if it
wishes. All I want is that the cache would never swap things out of main
memory, over some barrier which I can set (and may be zero, if I feel like
it).
2.2.0 should *not*, as far as small machines are involved, be released
without fixing this one way or the other. Currently, the performance is way
below 2.0.36.
This is the way I see things, at least.
Nimrod
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/