Linux users want better desktop performance (Screw data. Prioritize code)
Roy Bynum
rabynum at ieee.org
Tue Feb 17 22:59:26 UTC 2009
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.
More information about the desktop
mailing list