VM and swap - it's really unusable
Quoted 8 lines
Re: [2.4.17/18pre] VM and swap - it's really unusable
This is getting silly ... feeback like "ll is better than PK", "feels smooth", "is reponsive", "my kernel
compile is faster than yours", etc. is not getting us any closer to the "how" of making a better kernel.
Quoted 7 lines
What's the goal? How should SMP and NUMA behave? How is success measured?
It would be good to be very clear on the ultimate purpose before making radical changes. All of
these changes are dancing around some vague concept of reponsiveness...so define it!
OK, just my set of goals/requirements for a usable/production kernel:
- working VM under a broad set of loads. Working means fair/fitting treatment of cache vs. process memory, no OOM killing processes when there is plenty memory in "free+buffer+cache", no unnecessary swapping out of processes if there is plenty of "free+buffer+cache" memory.
- good/great interactive feel. This means no loss of interactivity due to cache vs. process memory issues. This means no loss of interactivity due to heavy IO.
- Good enough worst case latency for "amateur" audio/DVD playback.
What *I* do not need it "hard real-time" with 101% guaranteed response
times.
What *I* want is to see my goals in the stock kernel, without needing
to apply a weird set of patches :-)
How we get there I do not care to much. If -aa can solve the VM
problems, fine. If rmap solves them, great. Just bring a working, maintainable solution in.
Ditto for LL vs. preempt.
Martin
Signature · 5 lines
------------------------------------------------------------------ Martin Knoblauch | email: [email protected] TeraPort GmbH | Phone: +49-89-510857-309 C+ITS | Fax: +49-89-510857-111 http://www.teraport.de | Mobile: +49-170-4904759
Quoted 3 lines · Martin Knoblauch
How we get there I do not care to much. If -aa can solve the VM
problems, fine. If rmap solves them, great. Just bring a working, maintainable solution in.
It would be nice if you could try -aa and -rmap in your situation and give Andrea and me feedback on what needs to be improved in our patches (it's software, I assume it's not perfect ;)).
cheers,
Rik
Signature · 4 lines
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/Quoted 7 lines · Rik van Riel
Quoted 3 lines · Martin Knoblauch
How we get there I do not care to much. If -aa can solve the VM
problems, fine. If rmap solves them, great. Just bring a working, maintainable solution in.
Quoted 8 lines
It would be nice if you could try -aa and -rmap in your situation and give Andrea and me feedback on what needs to be improved in our patches (it's software, I assume it's not perfect ;)).
cheers,
Rik
OK, here we go. Just don't tell my boss what I did this afternoon :-)
My system:
----------
Toshiba Portege 7200, 650 MHz, 320 MB, 640 MB swap
My workload:
------------
- Netscape
- vmware with a 81 page ppt nightmare
- make dep clean modules bzImage
What I measure/observe:
-----------------------
- swapped out memory after starting up netscape and vmware/ppt
- reading mail/news using nestscape, some browsing
- alternating jumping throuth the ppt bullsh..
- swapped out memory after the make has finished
- suspending the vmware session
- how does it feel feelings
I did the tests with the following setups:
a) 2.4.17+vmscan-d+read_latency
b) 2.4.17-vmscan-d+read_latency+preempt+lock-break+miini-ll
c) 2.4.17+rmap11b
d) 2.4.18pre2aa2 (no aa patch that applies cleanly to 2.4.17 :-(
Results:
--------
a) 2.4.17+vmscan-d+read_latency
- after starting NS and vmware, there are 352K in swap
- when the kernel build is finished, there are less than 1M in swap and about 210 MB in Cache+Buffer
- vmware is pretty jerky during the make, loosing mouse and keyboard events
- system feels OK, while vmware suspends
- overall, the system is usable to me
b) 2.4.17-vmscan-d+read_latency+preempt+lock-break+mini-ll
- same VM behaviour as a)
- vmware session feels very smooth. No loss of events, smooth pointer movement
- no problems suspending vmware
- best result of all tested setups
OK, now one would have to find out which of the last three patches
gives the good feeling. And one would have to test against mini-ll or full-ll. Maybe tomorrow.
c) 2.4.17+rmap11b
- after starting netscape and vmware/ppt there are 744K in swap
- after the kernel build there are 40 MB in swap and 250 MB in Cache+Buffer
- vmware is jerky and sluggish during that time
- when the system is swapping out, it tends to freeze for several seconds
- system freezes when vmware gets suspended (large amount of writes)
Definitely, this combination does not the "excessive swap, althought
there is enough cache to shrink" problem. It also does not handle large IO very well. In the current state no candidate for me. Sorry Rick :-(
d) 2.4.18pre2aa2
- after starting NS and vmware, there are 352K in swap
- after the kernel build, there are 7 MB in swap, 220 MB in cache+buffer
- vmware is sluggish/jerky
- it freezes on swap-out
- it freezes on vmware-suspend
The swap dissaster looks better than rmap, but still worse than a and
b. Although the patch is big, it does not solve the problem of heavy writing freezing the system.
Conclusion for me, and maybe only me:
-------------------------------------
- the small fixes in vmscan-d+read_latency fix the swap-dissaster and IO freeze for me
- adding preempt+lock_break+mini_ll make the system *feel* great. That is important to me. Remember, this is a workstation. And a slow one. I really don't care about the last 5-10% of throughput, or the best worst case latency.
As a result I love b) and can very well live with a). For me, vmscan-d
and read_latency look like 2.4.18 candidates. For the added latency-improvement additional patches are acceptable.
rmap isn't worth the effort on *my* workload. Others may get totally
different mileage. And it is still better than mainline 2.4.17, which ends up with 60-70 MB in swap and unusable vmware and extended freezes.
-aa is slightly better in VM usage than rmap, but given the size of the
patch I am *personally* not to thrilled. Again, it doubtlessly fixes problems with other workloads on larger machines.
In the end, I still have no idea how to sort out the mess. At least I
know what setup is best for me today :-)
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected] TeraPort GmbH | Phone: +49-89-510857-309 C+ITS | Fax: +49-89-510857-111 http://www.teraport.de | Mobile: +49-170-4904759