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?