VM and swap - it's really unusable
Quoted 6 lines · On Mon, 7 Jan 2002 00:22:09 -0200 (BRST) Rik van Riel <[email protected]>…
Quoted 5 lines · Rik van Riel
Quoted 2 lines · Stephan von Krawczynski
I am pretty impressed by Martins test case where merely all VM patches fail with the exception of his own :-)
Quoted 6 lines
Quoted 1 line
No big wonder if both -aa and -rmap only get tested without swap ;)
To be clear ... -aa and -rmap should of course also work nicely without swap, no excuses for the bad behaviour shown in Martin's test, but at the moment they simply don't seem tuned for it.
Hi Rik,
My original goal was to find a VM that worked well w/o swap, not to show how each one acted with and without swap. Failing to find what I thought satisfactory I started my venture into VM by grepping the source for "Out of Memory:" and worked backwards from there not so very too long ago...
I did not swap test any VM until asked how my patch benched w/ respect to stock kernel w/ swap; others weren't left out intentionally I just never was asked.
Now that you "implied ;)" that it would be nice to see what other VM solutions look like with my test case i've attached an updated "boring column of numbers".
Here is how I would rank current VM options w/ respect to the _one_ test case I run. (Stephan has asked for an NFS server variant w/ my patch but I haven't tested it yet)
1st 2nd 3rd 4th w/o swap MH AA STOCK RMAP (ranked on VM pressure) w/ swap AA STOCK MH RMAP (ranked on sys time)
Observations:
a. rmap 10c, failed earlier than stock kernel thus doesn't qualify for use in my "no
swap" systems and it is still undergoing change and isn't mainline kernel yet; will revisit at intervals.
b. rc2aa2, while much better than stock has unexpected behaviour(s) I didn't like.
Namely, the konsole window running the tests was gone and KDE task bar were missing as well as some other windows and there was no indication by the kernel these processes were killed, only "VM: killing process cc1" and a few 0 order allocation failures (or something like that) at the end of the test.
c. mh patch probably doesn't swap enough but thus far there have been no bad reports
that can be directly attributed to this rather small change to vmscan.c
1. it works well under extreme VM pressure
2. it's performance is on par with the stock kernel and aa2
I glanced at rc2aa2 and it seems to be doing essentially what my patch does with a _lot_ of extra knobs some of which I don't like and I think I know why rc2aa2 doesn't perform quite as well under extreme pressure but I don't have the luxury of time to [dis]prove my ideas yet.
Haven't looked at rmap code yet...
Martin