“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.”
Can I now open 2000 nautilus window without problem ?
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.
You’re no fun, sometimes!
Don’t knock it until you try it.
Whoooooooaaaaaa what a rideeeeeee!!!!!!
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
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.
Multithreading is nothing without a good scheduler.
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
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.
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
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.
Just too bad that all those things were spinning teapots.
At least now we have spinning cubes.
Don’t forget Gears!!
And Haiku’s logo spinning letters, too.
😉
Edited 2010-11-19 08:12 UTC
I can’t wait until it is incorporated into some major distro. with a live CD.
I guess Con Kolivas appreciates, especially given how he was treated by other kernel devs.
Does this even relate to what Con was doing?
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?
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
That much is clear.
Use arguments
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
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!
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
Thanks
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
http://www.bargincomputing.com/2010/08/a-good-reason-to-use-pclinux…
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
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?
.
Edited 2010-11-17 16:41 UTC
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.
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.
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…
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
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
You should read this mate …
http://www.tmrepository.com/about/
From the article you linked:
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.
Hi,
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
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.
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
Good code was made better. Trolls move along.
Can’t wait to see what this does for my DAW…
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
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.
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.
http://marc.info/?l=linux-kernel&m=128978361700898&w=2
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