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

[Kevin Martin]

<snip>
> I read that [3] article and the first two things I noticed were the
> reference to "small RAM" which in the days of $11/GB RAM is rare, and
> that the author didn't touch the "dirty" tuning parameters, which are
> better suited to controlling the behavior of i/o buffers. He didn't
> mention tuning read ahead to speed reading of  application off the
> disk (which limits response even if lots of memory is free). In short
> the article is based on one trick, not a balanced approach to getting
> both responsive performance and good i/o performance.
>
> I regularly handle images 4x the size of memory, and in 33 days uptime
> have written a total of 109MB (from iostat) to swap. A balanced tune
> is far nicer than cranking swappiness as low as it will go and keeping
> crap in memory which is not needed (left over initialization code,
> error messages you never see, etc).
>
>> [1]
>> http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
>>
>> [2]
>> http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_boring.htm
>>
>> [3] http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm
>>
>
>

Bill, 

You don't mention what types of tuning you've done to enforce a
"balanced approach".  Any suggestions are greatly appreciated!

Kevin