[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)



Valent Turkovic wrote:
On Tue, Feb 17, 2009 at 8:19 PM, Valent Turkovic
<valent turkovic 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 tmr com>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


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