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

[Roy Bynum]

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.