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

[Bill Davidsen]

Valent Turkovic wrote:
> On Tue, Feb 17, 2009 at 8:19 PM, Valent Turkovic
> <valent.turkovic at gmail.com> wrote:
>> http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
>>
>> What is you comment?
>>
>> --
>> http://kernelreloaded.blog385.com/
>> linux, blog, anime, spirituality, windsurf, wireless
>> registered as user #367004 with the Linux Counter, http://counter.li.org.
>> ICQ: 2125241, Skype: valent.turkovic
>>
> 
> As a long time Linux desktop user and Linux enthusiast I want bloody
> screaming fast desktop :) There are some situations that I just want
> to pull my hair out when I see that desktop performance just crawls to
> a halt :(
> 
> When I read articles like Tales from responsivenessland[1] I really
> don't get why there aren't bells ringing in the heads of the people
> who can actually make a difference for Linux desktop performance.
> 
> I was also really sad when I read interview with Con Kolivas[2] and
> the reasons why he quit kernel development[3].
> 
I've known Kon for years, sent him patches for his 2.4 based "ck" kernel 
patches. But if you didn't read the LKML before he left, and can't follow the 
code, you see his point of view without context.

> I hope kernel developers will wake up and realise that there are also
> us - Desktop users and what we need and want are responsive desktops.
> 
> Will Fedora be the first Linux distro to have sane desktop defaults
> (vm.swappiness=1 and vm.vfs_cache_pressure=50). Current Fedora slogan
> is "Features. Freedom. Friends. First", I hope to see "Desktop
> performance" as part of it soon ;)
> 
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 Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot