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

[Matthew Woehlke]

Colin Walters wrote:
> 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).

The down-side, of course, is that less buffering will slow down whatever 
is trying to do I/O, which can cause the very responsiveness issues 
you're trying to fix.

> 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".

I think the default configuration is to reserve 40% of memory for 
buffering, and the rest for application memory (there is a kernel 
parameter to tune it, I forget what though).

Hmm... will quantum memory allow to store both buffer AND app memory in 
ram, such that the system will choose which is actually read (thereby 
"destroying" the other)? Because that's what we really need... otherwise 
you don't know if it's better to keep that file you just read, or the 
app memory that hasn't been touched in 30 minutes.

If you just read in a .cpp in a mass build (say, something the size of 
KDE), chances are you don't need it again... especially when the user 
goes back to writing that letter he stopped working on 30 minutes ago. 
Or maybe the user won't work on the letter and that file is the database 
the user is currently working with. The point is, there isn't a way to 
/know/, so the kernel has to just guess, and it favors (in its current 
configuration) new things.

> Though big picture if you're swapping very much you've basically lost.

Yes, but for someone like me, you need a HUGE amount of RAM to avoid 
swapping. I build KDE and do digital photography. The former needs 
probably a few GB of ram, at least (when you account for file buffering, 
especially in massively-parallel builds). The latter also needs a few GB 
of memory, especially if working on multiple images. I'd say 16 GB is a 
good number, but not so many desktops have that much (not yet at least). 
(Netbooks certainly don't, but then, you probably shouldn't be doing 
that sort of workload on a netbook in the first place.) Even hard-core 
web browsing can eat upwards of 1 GB (lots of sites open, especially 
graphics-heavy ones).

IOW, planning how to swap /well/ is still important, IMO.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
If a signature
is not read by anyone,
does it make a sound?