http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w...
What is you comment?
http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w... What is you comment?
My comment is that this may be one thing which improves perceived performance. However to say its that simple and changing this one property is all you need is a very bold statement.
Very often perceived performance has to do with how fast GUI apps react, and thats not really covered by that property at all.
- Clemens
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-w...
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 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 ;)
[1] http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w... [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
That's why I switched to FluxBox. Damn ugly, but fast. I don't need the fancy blinking windows, sliding menu's or whatever, But I see your problem: things like BlackBox tend to get too ugly/unhandy fast...
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-w...
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 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 ;)
[1] http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w... [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
On Fri, Feb 20, 2009 at 6:36 PM, Alex de Jong alexander.dejong@home.nl wrote:
That's why I switched to FluxBox. Damn ugly, but fast. I don't need the fancy blinking windows, sliding menu's or whatever, But I see your problem: things like BlackBox tend to get too ugly/unhandy fast...
At work I need access to Exchange 2007 server and untill new Gnome comes out with MAPI support I have to run Outlook under windows under Virtualbox.
The strange thing is that Firefox was running much faster under virtual machine than one running natively under Linux! I couldn't use native Firefox because somehow it would crawl... until I enabled these new options I saw recommended (vm.swappiness=1 and vm.vfs_cache_pressure=50). Now native running Firefox is as fast as one under virtual machine and I can finally use Firefox on Linux desktop...
Any comments?
On Fri, Feb 20, 2009 at 11:43 AM, Valent Turkovic valent.turkovic@gmail.com wrote:
On Fri, Feb 20, 2009 at 6:36 PM, Alex de Jong alexander.dejong@home.nl wrote:
That's why I switched to FluxBox. Damn ugly, but fast. I don't need the fancy blinking windows, sliding menu's or whatever, But I see your problem: things like BlackBox tend to get too ugly/unhandy fast...
At work I need access to Exchange 2007 server and untill new Gnome comes out with MAPI support I have to run Outlook under windows under Virtualbox.
The strange thing is that Firefox was running much faster under virtual machine than one running natively under Linux! I couldn't use native Firefox because somehow it would crawl... until I enabled these new options I saw recommended (vm.swappiness=1 and vm.vfs_cache_pressure=50). Now native running Firefox is as fast as one under virtual machine and I can finally use Firefox on Linux desktop...
Any comments?
-- 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
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
How about a new app: "system-config-performance"? Which would allow you to pick from several preconfigured profiles depending on your needs or the option to customize those settings.
Just an idea.
Richard
On Friday 20 February 2009 16:18:12 Richard Shaw wrote:
On Fri, Feb 20, 2009 at 11:43 AM, Valent Turkovic
valent.turkovic@gmail.com wrote:
On Fri, Feb 20, 2009 at 6:36 PM, Alex de Jong alexander.dejong@home.nl
wrote:
That's why I switched to FluxBox. Damn ugly, but fast. I don't need the fancy blinking windows, sliding menu's or whatever, But I see your problem: things like BlackBox tend to get too ugly/unhandy fast...
At work I need access to Exchange 2007 server and untill new Gnome comes out with MAPI support I have to run Outlook under windows under Virtualbox.
The strange thing is that Firefox was running much faster under virtual machine than one running natively under Linux! I couldn't use native Firefox because somehow it would crawl... until I enabled these new options I saw recommended (vm.swappiness=1 and vm.vfs_cache_pressure=50). Now native running Firefox is as fast as one under virtual machine and I can finally use Firefox on Linux desktop...
Any comments?
-- 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
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
How about a new app: "system-config-performance"? Which would allow you to pick from several preconfigured profiles depending on your needs or the option to customize those settings.
Just an idea.
Richard
That sounds like a cool idea!
How about a new app: "system-config-performance"?
Or maybe system-config-sanity would be better :-).
There are so many schizophrenic conflicts in linux, it would be nice to tame them all in one place.
Things like:
This thread talks about how the VM tuning seems to be for enterprise use, yet at the same time the new default NetworkManager system only works on laptops flitting about from one Starbucks to another.
The "prelinker" is enabled by default because one group of geeks want their shared libs to load 10 nanoseconds faster (while using 45 hours of cpu in a cron job to achieve that), meanwhile the security geeks enable address space randomization by default, thus insuring that everything the prelinker does will be for naught because none of the libs will ever load at the prelinked address.
And those are just off the top of my head - I'm sure there is lots more insanity out there.
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-w...
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-w... [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
On Fri, 2009-02-20 at 19:32 -0500, Bill Davidsen wrote:
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-w...
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-w... [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
Try getting rid of the bloat of some of the new desktop systems- kde4 is a real resource hog. I can't stop it from stealing my speed unless I kill the binaries in memory. And gnome is not that much better.
If you want real speed customise and maintain xdm and the smaller desktops like xfce and fvwm.
Tom Horsley wrote:
The "prelinker" is enabled by default because one group of geeks want their shared libs to load 10 nanoseconds faster (while using 45 hours of cpu in a cron job to achieve that), meanwhile the security geeks enable address space randomization by default, thus insuring that everything the prelinker does will be for naught because none of the libs will ever load at the prelinked address.
http://lwn.net/Articles/190139/:
In an attempt to restore some of the benefits of address space randomization, prelink is capable of randomly selecting the addresses used for prelinking. This makes it more difficult to perform certain attacks on a system, because the addresses used are unique to that system.
In other words, prelinking does address space randomization on a per-system basis.
Or so I understand – if you have any other sources, I’d be interested to hear them. This comes from a reputable source and matches my understanding.
Hope this helps,
James.
On Sat, 21 Feb 2009 14:53:29 +0000 James Wilkinson wrote:
In other words, prelinking does address space randomization on a per-system basis.
No doubt, but the address space randomization in the kernel happens every time any program is run and loads the shared libs at different random addresses without regard to any base address the prelinker may have assigned.
James Wilkinson wrote:
Tom Horsley wrote:
The "prelinker" is enabled by default because one group of geeks want their shared libs to load 10 nanoseconds faster (while using 45 hours of cpu in a cron job to achieve that), meanwhile the security geeks enable address space randomization by default, thus insuring that everything the prelinker does will be for naught because none of the libs will ever load at the prelinked address.
Thank you for the following.
http://lwn.net/Articles/190139/:
In an attempt to restore some of the benefits of address space randomization, prelink is capable of randomly selecting the addresses used for prelinking. This makes it more difficult to perform certain attacks on a system, because the addresses used are unique to that system.
In other words, prelinking does address space randomization on a per-system basis.
Or so I understand – if you have any other sources, I’d be interested to hear them. This comes from a reputable source and matches my understanding.
Hope this helps,
James.
<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-w...
[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
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-w...
What is you comment?
Do not blame the operating system for badly coded apps. Only the app knows if caching is a good idea.
Exerpt from "man -s 2 open" O_DIRECT (Since Linux 2.4.10) Try to minimize cache effects of the I/O to and from this file. In general this will degrade perfor- mance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, that is, at the completion of a read(2) or write(2), data is guaranteed to have been transferred. See NOTES below for further dis- cussion.
Valent Turkovic wrote:
http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w...
What is you comment?
I will have to try this at home. My home system is crawling and it could be related to some of these settings. I would like to see other fine tuning settings.
I cannot afford a new machine at this time.
Kevin Martin wrote:
<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!
Actually I did, there are some "dirty" parameters right where the swappiness lives, in /proc/sys/vm and making dirty_expire smaller pushes large writes out faster. You can also adjust the dirty*ratio values to speed cleansing. The details are in the "Documentation" directory of the kernel source (and elsewhere I guess, never looked).
using the "blockdev --setra" option to use a larger readahead will speed reads from the disk and bring programs in faster. Note that it also uses more memory, play with care on a small memory machine. This can take 30% off of boot time on some laptops with slow disk and GB+ ram (most recent laptops, in other words). Try powers of two starting at 4096 or so until it stops feeling better.
Mattias Hellström 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-w...
What is you comment?
Do not blame the operating system for badly coded apps. Only the app knows if caching is a good idea.
Exerpt from "man -s 2 open" O_DIRECT (Since Linux 2.4.10) Try to minimize cache effects of the I/O to and from this file. In general this will degrade perfor- mance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, that is, at the completion of a read(2) or write(2), data is guaranteed to have been transferred. See NOTES below for further dis- cussion.
Just let me add that DIRECT will usually slightly slow the i/o it's doing, but greatly reduce the impact on the system. This can really save performance of machines doing small transactions such as serving DNS, DHCP, mail, NNTP, of database lookups. The transaction per sec of the application can drop by 60% writing a large file, if you can pipe it through dd with the direct option it will hurt less.
So if the file i/o is non-critical there is a big gain to be had for the performance of some applications.
Robin Laing wrote:
Valent Turkovic wrote:
http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w...
What is you comment?
I will have to try this at home. My home system is crawling and it could be related to some of these settings. I would like to see other fine tuning settings.
I cannot afford a new machine at this time.
While I can, I'm waiting until the first price drop on the 4Q09 32nm Intel chips to do another build, so I'm not about to replace either. ;-) Maybe by then SSD will be at a better price point.
However, with memory floating about $11/GB most desktop and laptop systems can afford enough memory. Because most of these tuning issues address problems caused by not enough memory. Linux has gotten vastly larger in the last few years, and if you can match the memory to the requirement you will really improve performance.
Robin Laing wrote:
Valent Turkovic wrote:
http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-w...
What is you comment?
I will have to try this at home. My home system is crawling and it could be related to some of these settings. I would like to see other fine tuning settings.
I cannot afford a new machine at this time.
acer use these settings as default on the aspire one in linpus (which is based on fedora 8), though i think this was aimed more for the ssd versions to increase the ssd lifetime more than speed up the user experience