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? -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
