[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Matthew Woehlke wrote:
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.

I may be totally "out in the weeds" with this comment, but here goes. Is is possible to set up a small app that would maintain a record of the swap/buffer usage patterns and set up a "sliding scale" that would move the swap priority based on the usage pattern of the logged in user? I say this because different people tend to use their computers in different ways, as seen above. This would also allow a "starting point" for system tuning based on the amount of RAM and paging ratios. In the past I have had to do system tuning for Oracle DBs and know that different DB architectures require different tuning. It is a very technical art, generally beyond a nominal user. A usage tracking app may go a long way toward "auto tuning" based on usage patterns of particular users.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]