Linux users want better desktop performance (Screw data. Prioritize code)

[Colin Walters]

2009/2/17 Adam Jackson <ajax at 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-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
>>
>> 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).