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."
Order by: Score:
BeOS like ?
by boulabiar on Tue 16th Nov 2010 23:41 UTC
boulabiar
Member since:
2009-04-18

Can I now open 2000 nautilus window without problem ?

Reply Score: 3

RE: BeOS like ?
by Soulbender on Wed 17th Nov 2010 00:14 UTC in reply to "BeOS like ?"
Soulbender Member since:
2005-08-18

Maybe, maybe not? No-one opens 2000 Nautilus windows and no-one watches 10 movies and listens to 50 MP3's at the same time.
Maybe Linux is more concerned with being actaully usefull rather han boasting pointless accomplishments.

Reply Score: 5

RE[2]: BeOS like ?
by Tuishimi on Wed 17th Nov 2010 00:36 UTC in reply to "RE: BeOS like ?"
Tuishimi Member since:
2005-07-06

You're no fun, sometimes! ;)

Reply Score: 4

RE[2]: BeOS like ?
by Valhalla on Wed 17th Nov 2010 02:08 UTC in reply to "RE: BeOS like ?"
Valhalla Member since:
2006-01-24

Maybe, maybe not? No-one opens 2000 Nautilus windows and no-one watches 10 movies and listens to 50 MP3's at the same time.

Don't knock it until you try it.

Whoooooooaaaaaa what a rideeeeeee!!!!!!

Reply Score: 3

RE[2]: BeOS like ?
by rob_mx on Wed 17th Nov 2010 03:20 UTC in reply to "RE: BeOS like ?"
rob_mx Member since:
2005-08-04

Maybe, maybe not? No-one opens 2000 Nautilus windows and no-one watches 10 movies and listens to 50 MP3's at the same time.
Maybe Linux is more concerned with being actaully usefull rather han boasting pointless accomplishments.


No, but there are people that use audio editing applications with dozens of audio channels where latency matters. That is where being able to play 50 streams of audio at the same time without hiccups might be useful ;)

Reply Score: 5

RE[3]: BeOS like ?
by f0dder on Wed 17th Nov 2010 07:58 UTC in reply to "RE[2]: BeOS like ?"
f0dder Member since:
2009-08-05

Hopefully no audio application uses one thread per channel while mixing.

Reply Score: 1

RE[4]: BeOS like ?
by Laurence on Wed 17th Nov 2010 17:41 UTC in reply to "RE[3]: BeOS like ?"
Laurence Member since:
2007-03-26

Hopefully no audio application uses one thread per channel while mixing.

Sequencers might and there would be a genuine justification for them in doing so.

Reply Score: 2

RE[4]: BeOS like ?
by phoudoin on Fri 19th Nov 2010 08:04 UTC in reply to "RE[3]: BeOS like ?"
phoudoin Member since:
2006-06-09

Multithreading is nothing without a good scheduler.

Reply Score: 2

RE[2]: BeOS like ?
by Fergy on Wed 17th Nov 2010 14:22 UTC in reply to "RE: BeOS like ?"
Fergy Member since:
2006-04-10

Maybe, maybe not? No-one opens 2000 Nautilus windows and no-one watches 10 movies and listens to 50 MP3's at the same time.
Maybe Linux is more concerned with being actaully usefull rather han boasting pointless accomplishments.

If you gave Win95 32MB of memory and a P200 it would run really nice and as long as you didn't do too much(more than 1 heavy program) with it. Now if I have a system with 3200MB of memory and 4x a P2000 I should in theory be able to do at least 10x as much without any stutters.
Something went wrong with multitasking desktops and this patch seems so be a big step towards fixing it.

Edited 2010-11-17 14:23 UTC

Reply Score: 1

RE[3]: BeOS like ?
by helf on Wed 17th Nov 2010 14:44 UTC in reply to "RE[2]: BeOS like ?"
helf Member since:
2005-07-06

My pentium 75 laptop with 40mb of ram running windows 95 begs to differ :p

(I run windows since the CT65565 video card has crap linux support and I don't wanna just run with a cli)

Reply Score: 2

RE[4]: BeOS like ?
by Fergy on Wed 17th Nov 2010 14:51 UTC in reply to "RE[3]: BeOS like ?"
Fergy Member since:
2006-04-10

My pentium 75 laptop with 40mb of ram running windows 95 begs to differ :p

(I run windows since the CT65565 video card has crap linux support and I don't wanna just run with a cli)

Do you mean that win95 did not run smooth with 32MB and P200 or that higher specs 40MB did not even run smooth?

Your reply answers nothing and raises at least 2 questions.

Reply Score: 1

RE[5]: BeOS like ?
by helf on Wed 17th Nov 2010 14:54 UTC in reply to "RE[4]: BeOS like ?"
helf Member since:
2005-07-06

Guess it was a bit unclear, sorry, I've only been awake for 45 minutes.

I meant that Windows 95 will run more than acceptably with more than 1 program on p1-200 with 32mb ram.

My p1-75 with 40mb runs multiple PuTTY SSH2 sessions, IRC, OffByOne browser with multiple tabs, and playing mp3s off a CF card just fine ;) At any given moment I have 2-10mb of free ram and it will beu sing maybe 15mb of swap (mostly offbyone being cached out from lack of use).

I'll try to make my posts more clear ;)

Reply Score: 2

RE: BeOS like ?
by evert on Wed 17th Nov 2010 09:24 UTC in reply to "BeOS like ?"
evert Member since:
2005-07-06

I agree that BeOS / Haiku was indeed able to do an awful lot of things at the same time, while still being responsive. Much better than Windows or Linux on the desktop.

But server-side... I would rather run Linux than Haiku for deamons ;-)

This patch tries to combine both benefits: a kernel usable for both server and desktop, even at the same time.

Reply Score: 2

RE[2]: BeOS like ?
by No it isnt on Wed 17th Nov 2010 09:45 UTC in reply to "RE: BeOS like ?"
No it isnt Member since:
2005-11-14

Just too bad that all those things were spinning teapots.

Reply Score: 2

RE[3]: BeOS like ?
by jbauer on Wed 17th Nov 2010 13:14 UTC in reply to "RE[2]: BeOS like ?"
jbauer Member since:
2005-07-06

Just too bad that all those things were spinning teapots.


At least now we have spinning cubes.

Reply Score: 2

RE[4]: BeOS like ?
by looncraz on Wed 17th Nov 2010 15:26 UTC in reply to "RE[3]: BeOS like ?"
looncraz Member since:
2005-07-24

Don't forget Gears!!

Reply Score: 2

RE[4]: BeOS like ?
by phoudoin on Fri 19th Nov 2010 08:09 UTC in reply to "RE[3]: BeOS like ?"
phoudoin Member since:
2006-06-09

And Haiku's logo spinning letters, too.
;-)

Edited 2010-11-19 08:12 UTC

Reply Score: 2

This sounds sweet!
by Tuishimi on Wed 17th Nov 2010 00:39 UTC
Tuishimi
Member since:
2005-07-06

I can't wait until it is incorporated into some major distro. with a live CD.

Reply Score: 2

Comment by Radio
by Radio on Wed 17th Nov 2010 05:31 UTC
Radio
Member since:
2009-06-20

I guess Con Kolivas appreciates, especially given how he was treated by other kernel devs.

Reply Score: 2

RE: Comment by Radio
by Soulbender on Wed 17th Nov 2010 08:29 UTC in reply to "Comment by Radio"
Soulbender Member since:
2005-08-18

Does this even relate to what Con was doing?

Reply Score: 2

RE[2]: Comment by Radio
by renox on Wed 17th Nov 2010 09:23 UTC in reply to "RE: Comment by Radio"
renox Member since:
2005-07-06

Not really, this patch is for a really specialised case: ensuring that one tty doesn't hog all the CPU(s)..
It does nothing when various applications have the same tty which is the case for all the GUI applications.
But this is still an interesting improvement, I wonder if BFS would be improved by a similar change?

Reply Score: 4

v Comment by tetek
by tetek on Wed 17th Nov 2010 09:04 UTC
RE: Comment by tetek
by Soulbender on Wed 17th Nov 2010 09:10 UTC in reply to "Comment by tetek"
Soulbender Member since:
2005-08-18

I really don't get it


That much is clear.

Reply Score: 3

RE[2]: Comment by tetek
by tetek on Wed 17th Nov 2010 10:01 UTC in reply to "RE: Comment by tetek"
tetek Member since:
2010-10-04

Use arguments

Reply Score: 1

RE[3]: Comment by tetek
by gilboa on Wed 17th Nov 2010 11:18 UTC in reply to "RE[2]: Comment by tetek"
gilboa Member since:
2005-07-06

Your question is based on two assumptions:
A. Kernel development (especially code profiling) is easy.
B. Finding the right balance between interactive and non-interactive processes is easy - especially when dealing with generic kernel schedulers, such as the Linux scheduler.

- Gilboa

Reply Score: 4

RE[4]: Comment by tetek
by tetek on Wed 17th Nov 2010 12:03 UTC in reply to "RE[3]: Comment by tetek"
tetek Member since:
2010-10-04

OK, but Linux has community for about what? 15 years? For 15 years no one done it right? What changed? It was pure luck? We have now better tools? We are smarter now (as a population)? We know more about operation systems theory?
And especially - why no one bother to do it earlier? It's system core - it has to be top - notch!

Reply Score: 1

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 Score: 6

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

Thanks

Reply Score: 1

RE[6]: Comment by tetek
by lemur2 on Wed 17th Nov 2010 22:22 UTC 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 Score: 3

RE[5]: Comment by tetek
by asdf on Wed 17th Nov 2010 13:46 UTC in reply to "RE[4]: Comment by tetek"
asdf Member since:
2009-09-23

Sigh, it has been improved for certain use cases. What the hell is so difficult about that? Gees, what do phrases like "done right", "top-notch" even mean outside of marketing context?

Reply Score: 1

RE[5]: Comment by tetek
by Soulbender on Wed 17th Nov 2010 16:38 UTC in reply to "RE[4]: Comment by tetek"
Soulbender Member since:
2005-08-18

.

Edited 2010-11-17 16:41 UTC

Reply Score: 2

RE[5]: Comment by tetek
by Laurence on Wed 17th Nov 2010 17:49 UTC in reply to "RE[4]: Comment by tetek"
Laurence Member since:
2007-03-26

OK, but Linux has community for about what? 15 years? For 15 years no one done it right? What changed? It was pure luck? We have now better tools? We are smarter now (as a population)? We know more about operation systems theory? And especially - why no one bother to do it earlier? It's system core - it has to be top - notch!

Aside what the others have already answered, I'd like to add the following:
Windows' kernel is under constant development too. In fact, this is the case for all kernels on all active OSs.

Reply Score: 2

RE: Comment by tetek
by mansz on Wed 17th Nov 2010 09:15 UTC in reply to "Comment by tetek"
mansz Member since:
2010-11-17

Well the thing is that Linus have always wanted the kernel to be as generic as possible so he did not want to put in to may scheduler in the Linux kernel. And since Linux is developed not only to run on a desktop the scheduler have not always been optimized for desktop use. Windows and probably OSX scheduler have alway been prioritized GUI processes before the none GUI processes but this is an area that Linux have been lacking. There is patches for this but Linus did not want them to be part of the kernel since he do not want to may schedulers. This patch should probably solve this issue.

Reply Score: 2

RE: Comment by tetek
by lemur2 on Wed 17th Nov 2010 09:20 UTC in reply to "Comment by tetek"
lemur2 Member since:
2007-02-17

I don't get it - it's big halo cause linux programmers just discover that writing good code gives you good performance or that linux kernel is seriously flawed and needs work ASAP? And all that whining "linux is the best" was bullshit? I really don't get it ;)


The performance of the Linux kernel is absolutely fine for some kinds of roles. World best, in fact.

Backup:
http://www.networkworld.com/community/blog/microsoft-breaks-petaflo...
Microsoft says a Windows-based supercomputer has broken the petaflop speed barrier, but the achievement is not being recognized by the group that tracks the world's fastest supercomputers, because the same machine was able to achieve higher speeds using Linux.


In that case, Windows HPC would have made the top 5 in the highest-performing supercomputer listsing (which BTW is dominated by Linux machines) for the first time had it not been for the fact that Linux performed better on the same machine.

Having said all of that ... it should be noted that Linux to date has not been particularly well optimised for desktop loads. This patch helps considerably to get around that, apparently.

Perhaps with this patch desktop Linux will henceforth perform better on the same hardware than desktop Windows, just as has been the case before this point in time for embedded Linux vs embedded Windows, server Linux vs server Windows, and HPC Linux vs HPC Windows.

Edited 2010-11-17 09:31 UTC

Reply Score: 1

RE[2]: Comment by tetek
by Kebabbert on Wed 17th Nov 2010 11:58 UTC in reply to "RE: Comment by tetek"
Kebabbert Member since:
2007-07-27

"I don't get it - it's big halo cause linux programmers just discover that writing good code gives you good performance or that linux kernel is seriously flawed and needs work ASAP? And all that whining "linux is the best" was bullshit? I really don't get it ;)


The performance of the Linux kernel is absolutely fine for some kinds of roles. World best, in fact.

Backup:
http://www.networkworld.com/community/blog/microsoft-breaks-petaflo...
Microsoft says a Windows-based supercomputer has broken the petaflop speed barrier, but the achievement is not being recognized by the group that tracks the world's fastest supercomputers, because the same machine was able to achieve higher speeds using Linux.
"
This is not a valid conclusion. It says nothing about other OSes, such as Solaris.

This only proves that Linux is faster than Windows. This does not prove that Linux is fastest in the world, nor World's best.

Reply Score: 3

RE[3]: Comment by tetek
by lemur2 on Wed 17th Nov 2010 21:57 UTC in reply to "RE[2]: Comment by tetek"
lemur2 Member since:
2007-02-17

This is not a valid conclusion. It says nothing about other OSes, such as Solaris. This only proves that Linux is faster than Windows. This does not prove that Linux is fastest in the world, nor World's best.


That particular case says nothing about other OSes, I agree.

However, then entirity of the Top 500 supercomputers list does have something to say in the arena of the highest of performance, most expensive machines in the world.

Here are the current statistics, Nov 2010

http://www.top500.org/stats/list/36/osfam

Linux has 91.80 % share of this list. Remember that this is the list where only performance matters, and cost is a minor concern, even if it is a consideration at all.

Traditional Unix (such as Solaris would be counted amongst) gets a notable 3.80%. "Mixed" operating systems of various kinds represent 3.2% of the list, and Windows comes in with a 1% share.

Linux has the world's high-performance computing market pretty much cornered. Once could indeed mount a fair case from these figures that Linux is indeed the fastest in the world, and the World's best.

Now, would you like perhaps to look at embedded, or maybe servers? Other OSes do get a bit of a look in there.

Edited 2010-11-17 22:00 UTC

Reply Score: 3

RE[2]: Comment by tetek
by lucas_maximus on Wed 17th Nov 2010 12:59 UTC in reply to "RE: Comment by tetek"
lucas_maximus Member since:
2009-08-18

You should read this mate ...

http://www.tmrepository.com/about/

Reply Score: 1

RE[2]: Comment by tetek
by Stratoukos on Wed 17th Nov 2010 15:40 UTC in reply to "RE: Comment by tetek"
Stratoukos Member since:
2009-02-11

From the article you linked:

The Tsubame team ran their Top 500 benchmarking tests on both Linux and Windows, and the difference in performance was less than 5% but Linux did come out on top, Hilf says. Hilf attributes Linux's slim victory to the Tokyo researchers running the Linux tests on a slightly larger number of nodes. I'm not sure why the tests were run on a different number of nodes, but I will be interviewing Matsuoka at this week's SC10 supercomputing conference in New Orleans and will attempt to find out.

I think I know why. It's because on a machine that probably needs millions of dollars just to flip the switch, there are more important things than just nailing a benchmark.

I don't know if Linux is more efficient than Windows in HPC, but the article you linked doesn't say much either.

Reply Score: 3

RE[3]: Comment by tetek
by Brendan on Wed 17th Nov 2010 21:14 UTC in reply to "RE[2]: Comment by tetek"
Brendan Member since:
2005-11-16

Hi,

I don't know if Linux is more efficient than Windows in HPC, but the article you linked doesn't say much either.


For HPC there's a tendency to split a large amount of work into "one piece per CPU". This makes the scheduler mostly irrelevant (it's simple to decide which piece of work the CPU should be doing when there's only 1 piece of work the CPU can be doing). The performance difference probably comes from something else (e.g. maybe Linux has more efficient networking).

When you're running a wide variety of different tasks (with different characteristics), then the scheduler becomes important. I've said for a long time that the scheduling in Linux is flawed, because most processes can't tell the scheduler anything about their characteristics, and therefore the scheduler doesn't have the information needed to make good decisions.

In contrast, there's lots of OSs that are better for desktop interactivity than Linux (including Windows) because tasks/processes do tell the scheduler something about their characteristics. For example, for Windows there's a "priority class" and a "base priority" within that class. For Linux there is a "scheduling class" (but the same scheduling class is used by almost everything and doesn't allow for the equivalent of a "base priority").

This patch helps to hide a symptom of the problem (and helps to illustrate how bad the problem is), but hiding symptoms isn't the same as finding a cure.

- Brendan

Reply Score: 3

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

From the article you linked: "The Tsubame team ran their Top 500 benchmarking tests on both Linux and Windows, and the difference in performance was less than 5% but Linux did come out on top, Hilf says. Hilf attributes Linux's slim victory to the Tokyo researchers running the Linux tests on a slightly larger number of nodes. I'm not sure why the tests were run on a different number of nodes, but I will be interviewing Matsuoka at this week's SC10 supercomputing conference in New Orleans and will attempt to find out.
I think I know why. It's because on a machine that probably needs millions of dollars just to flip the switch, there are more important things than just nailing a benchmark. I don't know if Linux is more efficient than Windows in HPC, but the article you linked doesn't say much either. "

http://www.top500.org/stats/list/36/osfam

Linux = 91.80 % share of supercomputers, which are the world's most expensive of machines, where only performance matters.

Windows HPC = 1%.

Draw your own conclusions.

Reply Score: 2

RE[2]: Comment by tetek
by morglum666 on Wed 17th Nov 2010 21:04 UTC in reply to "RE: Comment by tetek"
morglum666 Member since:
2005-07-06

In shocking news, operating systems that don't maintain a 20+ year compatibility run faster than ones that do.

Reply Score: 2

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

In shocking news, operating systems that don't maintain a 20+ year compatibility run faster than ones that do.


Windows HPC doesn't maintain a 20+ year binary compatibility.

Most Linux systems will be able to compile & run source code written 20 years ago without much problem.

Edited 2010-11-17 22:08 UTC

Reply Score: 2

RE: Comment by tetek
by korpenkraxar on Wed 17th Nov 2010 10:11 UTC in reply to "Comment by tetek"
korpenkraxar Member since:
2005-09-10

Good code was made better. Trolls move along.

Reply Score: 5

Absolutely love it
by mtemmerm on Wed 17th Nov 2010 11:02 UTC
mtemmerm
Member since:
2009-07-31

Can't wait to see what this does for my DAW...

Reply Score: 1

Sounds familiar
by Paradroid on Wed 17th Nov 2010 12:01 UTC
Paradroid
Member since:
2010-01-05

Can we christen this the Amiga patch?

Sounds like it does for Linux what the Amiga did in the 1980's and Windows has done as well - multitask smoothly and keep a responsive UI under load ;)

Reply Score: 0

RE: Sounds familiar
by helf on Wed 17th Nov 2010 14:50 UTC in reply to "Sounds familiar"
helf Member since:
2005-07-06

Heh, I need to test this patch out. It WILL be nice to not have so much UI stuttering when something is going on.

My bloody NeXT running at 33mhz had a smoother UI under heavy load than my core2 box running ubuntu.

Reply Score: 2

RE[2]: Sounds familiar
by viton on Wed 17th Nov 2010 20:58 UTC in reply to "RE: Sounds familiar"
viton Member since:
2005-08-09

Yeah, it is a great shame what even smooth scrolling todays become so expensive what some background console processes can mess with it.
I had 50hz v-synced scroll in ZX-Spectrum text editor back then.

Reply Score: 2

The patch, and some testing numbers
by lemur2 on Thu 18th Nov 2010 00:07 UTC
lemur2
Member since:
2007-02-17

http://marc.info/?l=linux-kernel&m=128978361700898&w=2

Average service latency is an order of magnitude better with autogroup.
(Imagine that pert were Xorg or whatnot instead)

Using Mathieu Desnoyers' wakeup-latency testcase:

With taskset -c 3 make -j 10 running..

taskset -c 3 ./wakeup-latency& sleep 30;killall wakeup-latency

without:
maximum latency: 42963.2 µs
average latency: 9077.0 µs
missed timer events: 0

with:
maximum latency: 4160.7 µs
average latency: 149.4 µs
missed timer events: 0


An order of magnitude improvement in latency for a small patch has got to be worthwhile.

Average latency improved from about 1 millisecond down to 150 microseconds. Maximum latency improved from 42 milliseconds down to 4 milliseconds.

Edited 2010-11-18 00:11 UTC

Reply Score: 2