2009/2/17 Adam Jackson <ajax@xxxxxxxxxx>: > 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). -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
