Linked by Thom Holwerda on Tue 16th Nov 2010 22:48 UTC, submitted by Michael
Linux "In recent weeks and months there has been quite a bit of work towards improving the responsiveness of the Linux desktop with some very significant milestones building up recently and new patches continuing to come. This work is greatly improving the experience of the Linux desktop when the computer is withstanding a great deal of CPU load and memory strain. Fortunately, the exciting improvements are far from over. There is a new patch that has not yet been merged but has undergone a few revisions over the past several weeks and it is quite small - just over 200 lines of code - but it does wonders for the Linux desktop."
Thread beginning with comment 450309
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by tetek
by gilboa on Wed 17th Nov 2010 13:35 UTC in reply to "RE[4]: Comment by tetek"
gilboa
Member since:
2005-07-06

EDIT: Re-reading. Comment too aggressive. Please ignore.

Long answer.
1. During the past -19- years, the Linux scheduler has changed more than once. Each was designed with a different workload in mind; Each was designed to used on a different hardware. (Important!)
2. During the years, that average server moved from a dual socket / dual CPU's to dual/quad socket / 6-12 (!!!) cores / 12 threads. The average workstation jumped from a single CPU to 4-12 cores/threads.
3. The CFQ scheduler is ~3 year old.
4. The Linux kernel is fairly well suited for server workloads.

Now, given the above, the Linux scheduler is under constant development as the baseline requirements continue to evolve (See item 2). As developers gain experience with the relatively new CFQ scheduler and the new hardware classes (E.g. 24 thread workstations and 12 thread desktops), they gain new insight into the how to solve existing (and new) problems - in this case: low responsiveness (?) when dealing with desktop workloads.
Keep in mind that while trying to fix this problem, the scheduler developers must be certain that their patches do not drop the kernel's server workload performance, as the server market is Linux' bread and butter.

You are reading far too much into the size of the patch.

- Gilboa

Edited 2010-11-17 13:53 UTC

Reply Parent Score: 6

RE[6]: Comment by tetek
by tetek on Wed 17th Nov 2010 14:55 in reply to "RE[5]: Comment by tetek"
tetek Member since:
2010-10-04

Thanks

Reply Parent Score: 1

RE[6]: Comment by tetek
by lemur2 on Wed 17th Nov 2010 22:22 in reply to "RE[5]: Comment by tetek"
lemur2 Member since:
2007-02-17

EDIT: Re-reading. Comment too aggressive. Please ignore. Long answer. 1. During the past -19- years, the Linux scheduler has changed more than once. Each was designed with a different workload in mind; Each was designed to used on a different hardware. (Important!) 2. During the years, that average server moved from a dual socket / dual CPU's to dual/quad socket / 6-12 (!!!) cores / 12 threads. The average workstation jumped from a single CPU to 4-12 cores/threads. 3. The CFQ scheduler is ~3 year old. 4. The Linux kernel is fairly well suited for server workloads. Now, given the above, the Linux scheduler is under constant development as the baseline requirements continue to evolve (See item 2). As developers gain experience with the relatively new CFQ scheduler and the new hardware classes (E.g. 24 thread workstations and 12 thread desktops), they gain new insight into the how to solve existing (and new) problems - in this case: low responsiveness (?) when dealing with desktop workloads. Keep in mind that while trying to fix this problem, the scheduler developers must be certain that their patches do not drop the kernel's server workload performance, as the server market is Linux' bread and butter. You are reading far too much into the size of the patch. - Gilboa


Indeed.

Mind you, not every Linux distribution is aimed at the server market, some distributions are aimed specifically at the desktop. Sometimes the people know what they are doing, and they replace the standard Linux scheduler, designed for server workloads (or at least it is only a compromise), with another option which has desktop usage more in mind:

http://distrowatch.com/?newsid=06098
"Zenwalk Linux 6.4 provides many enhancements at system and application levels, while confirming the maturity and feature stability of Zenwalk. The brand new 2.6.33.4 kernel is featuring the new BFS scheduler, designed for the best desktop interactivity on multi-core CPUs while taking the most of lower specification machines. You'll notice better responsiveness of graphical applications, better real-time performance of sound applications (very low latency), and efficiency of 'niced' commands (compilation tasks can really be niced in a way they don't disturb other applications)."


http://www.bargincomputing.com/2010/08/a-good-reason-to-use-pclinux...
At this time, only Zenwalk 6.4 and PCLinuxOS 2010 use BFS as the default scheduler. As it matures, you may see BFS appear in other mobile projects, such as MeeGo.


It isn't done widely, but perhaps this shows the beauty of FOSS. You don't have to all use the same thing, you can pick and choose amongst alternatives. "Fragmentation" isn't necessarily a dirty word.

Edited 2010-11-17 22:24 UTC

Reply Parent Score: 3