Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 16 Jan 1999 11:54:59 +0200 | From | Nimrod Zimerman <> | Subject | VM20 behavior on a 486DX/66Mhz with 16mb of RAM |
| |
Hello.
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/
| ![\](/images/icornerr.gif) |