2009/2/17 Adam Jackson <ajax(a)redhat.com>:
On Tue, 2009-02-17 at 20:19 +0100, Valent Turkovic wrote:
>
http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenesslan...
>
> What is you comment?
If we really thought this was true, it would be straightforward enough
to bump the mlock limits for users and get some of the high-touch apps
to lock their text sections. I can add this to the X server tomorrow
trivially even without that (the joys of being root).
I'm not _that_ convinced. I mean, the way to measure this is to look at
the io trace hooks and see what you end up reading in. I'd be mildly
surprised if it was text sections.
Ok, I only skimmed his article initially, I thought his argument was
basically that it's better for interactivity to have a smaller buffer
cache than to (preemptively or not) page out application sections (be
that text, or stack/heap).
Certainly in the default configuration, the heap can be paged out, no?
I think by "Prioritize code." he really means "whatever the app needs
to respond to user input".
This is apparently not a new debate:
http://kerneltrap.org/node/3000
Though big picture if you're swapping very much you've basically lost.
So the biggest wins here definitely involve fixing applications (like
federico's work on image caching and jemalloc in Firefox, alex's
recent blog about tracking down extra nautilus heap usage).