Discussion continues regarding the choice to merge the CFS scheduler into the upcoming 2.6.23 kernel. A recent thread looked at the possibility of having merged the plugsched code to allow for both the CFS and SD schedulers to coexist in the mainline kernel at the same time, thereby avoiding the recent flamewars. Linus Torvalds pointed to the ManagementStyle documentation and acknowledged that while it's better to avoid flamefests when possible, "at the same time, I don't like playing politics with technology. The kernel is a technical project, and I make technical decisions. So I absolutely detest adding code for 'political' reasons."
As to the technical reason why he wasn't interested in making the CPU scheduler pluggable, Linus explained, "this is one approach, but it's actually one that I personally think is often the worst possible choice. Why? Because it ends up meaning that you never get the cross-pollination from different approaches (they stay separate 'modes'), and it's also usually really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of." He went on to note, "I personally think that it's much better to find a setup that works 'well enough' for people, without having modal behaviour. People complain and gripe now, but what people seem to be missing is that it's a journey, not an end-of-the-line destination. We haven't had a single release kernel with the new scheduler yet". He added, "this, btw, has nothing to do with schedulers per se. We have had these exact same issues in the memory management too - which is a lot more complex than scheduling".
Linus continued:
"This is also, btw, why I think that people who argue for splitting desktop kernels from server kernels are total morons, and only show that they don't know what the hell they are talking about.
"The fact is, the work we've done on server loads has improved the desktop experience _immensely_, with all the scalability work (or the work on large memory configurations, etc etc) that went on there, and that used to be totally irrelevant for the desktop.
"And btw, the same is very much true in reverse: a lot of the stuff that was done for desktop reasons (hotplug etc) has been a _huge_ boon for the server side, and while there were certainly issues that had to be resolved (the sysfs stuff so central to the hotplug model used tons of memory when you had ten thousand disks, and server people were sometimes really unhappy), a lot of the big improvements actually happen because something totally _unrelated_ needed them, and then it just turns out that it's good for the desktop too, even if it started out as a server thing or vice versa.
"This is why the whole 'modal' mindset is stupid. It basically freezes a choice that shouldn't be frozen. It sets up an artificial barrier between two kinds of uses (whether they be about 'server' vs 'desktop' or '3D gaming' vs 'audio processing', or anything else), and that frozen choice actually ends up being a barrier to development in the long run.
"So 'modal' things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one)"
From: Jan Engelhardt [email blocked] Subject: Re: [ck] Re: Linus 2.6.23-rc1 Date: Sat, 28 Jul 2007 19:33:38 +0200 (CEST) On Jul 28 2007 10:12, Linus Torvalds wrote: > >The fact is, I've _always_ considered the desktop to be the most important >part. [...] >The fact is, most kernel developers realize that Linux is used in >different places, on different machines, and with different loads. You >cannot make _everybody_ happy, but you can try to do as good a job as >possible. And doing "as good a job as possible" very much includes not >focusing on any particular load. You cannot please everybody in the scheduler question, that is clear, then why not offer dedicated scheduling alternatives (plugsched comes to mind) and let them choose what pleases them most, and handles their workload best? Jan
From: Linus Torvalds [email blocked] Subject: Re: [ck] Re: Linus 2.6.23-rc1 Date: Sat, 28 Jul 2007 11:05:25 -0700 (PDT) On Sat, 28 Jul 2007, Jan Engelhardt wrote: > > You cannot please everybody in the scheduler question, that is clear, > then why not offer dedicated scheduling alternatives (plugsched comes to mind) > and let them choose what pleases them most, and handles their workload best? This is one approach, but it's actually one that I personally think is often the worst possible choice. Why? Because it ends up meaning that you never get the cross-pollination from different approaches (they stay separate "modes"), and it's also usually really bad for users in that it forces the user to make some particular choice that the user is usually not even aware of. So I personally think that it's much better to find a setup that works "well enough" for people, without having modal behaviour. People complain and gripe now, but what people seem to be missing is that it's a journey, not an end-of-the-line destination. We haven't had a single release kernel with the new scheduler yet, so the only people who have tried it are either (a) interested in schedulers in the first place (which I think is *not* a good subset, because they have very specific expectations of what is right and what is wrong, and they come into the whole thing with that mental baggage) (b) people who test -rc1 kernels (I love you guys, but sadly, you're not nearly as common as I'd like ;) so the fact is, we'll find out more information about where CFS falls down, and where it does well, and we'll be able to *fix* it and tweak it. In contrast, if you go for a modal approach, you tend to always fixate those two modes forever, and you'll never get something that works well: people have to switch modes when they switch workloads. [ This, btw, has nothing to do with schedulers per se. We have had these exact same issues in the memory management too - which is a lot more complex than scheduling, btw. The whole page replacement algorithm is something where you could easily have "specialized" algorithms in order to work really well under certain loads, but exactly as with scheduling, I will argue that it's a lot better to be "good across a wide swath of loads" than to try to be "perfect in one particular modal setup". ] This is also, btw, why I think that people who argue for splitting desktop kernels from server kernels are total morons, and only show that they don't know what the hell they are talking about. The fact is, the work we've done on server loads has improved the desktop experience _immensely_, with all the scalability work (or the work on large memory configurations, etc etc) that went on there, and that used to be totally irrelevant for the desktop. And btw, the same is very much true in reverse: a lot of the stuff that was done for desktop reasons (hotplug etc) has been a _huge_ boon for the server side, and while there were certainly issues that had to be resolved (the sysfs stuff so central to the hotplug model used tons of memory when you had ten thousand disks, and server people were sometimes really unhappy), a lot of the big improvements actually happen because somethng totally _unrelated_ needed them, and then it just turns out that it's good for the desktop too, even if it started out as a server thing or vice versa. This is why the whole "modal" mindset is stupid. It basically freezes a choice that shouldn't be frozen. It sets up an artificial barrier between two kinds of uses (whether they be about "server" vs "desktop" or "3D gaming" vs "audio processing", or anything else), and that frozen choice actually ends up being a barrier to development in the long run. So "modal" things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one) Linus
From: Diego Calleja [email blocked] Subject: Re: [ck] Re: Linus 2.6.23-rc1 Date: Sat, 28 Jul 2007 22:51:48 +0200 El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds [email blocked] escribió: > So "modal" things are good for fixing behaviour in the short run. But they > are a total disaster in the long run, and even in the short run they tend > to have problems (simply because there will be cases that straddle the > line, and show some of _both_ issues, and now *neither* mode is the right > one) I fully agree with this, but plugsched could have avoided this useless "division" on the topic of SD vs CFS. IMO that counts as an advantage, too ;)
From: Linus Torvalds [email blocked] Subject: Re: [ck] Re: Linus 2.6.23-rc1 Date: Sat, 28 Jul 2007 14:09:46 -0700 (PDT) On Sat, 28 Jul 2007, Diego Calleja wrote: > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds [email blocked] escribió: > > > > So "modal" things are good for fixing behaviour in the short run. But they > > are a total disaster in the long run, and even in the short run they tend > > to have problems (simply because there will be cases that straddle the > > line, and show some of _both_ issues, and now *neither* mode is the right > > one) > > I fully agree with this, but plugsched could have avoided this useless "division" > on the topic of SD vs CFS. IMO that counts as an advantage, too ;) Sure. I actually think it's a huge advantage (see the ManagementStyle file on pissing people off), but at the same time, I don't like playing politics with technology. The kernel is a technical project, and I make technical decisions. So I absolutely detest adding code for "political" reasons. I personally feel that modal behaviour is bad, so it would introduce what is in my opinion bad code, and likely result in problems not being found and fixed as well (because people would pick the thing that "works for them", and ignore the problems in the other module). So while I don't like making irreversible decisions (and the choice of CFS wasn't irreversible in itself, but if it pisses off Con, _that_ is generally not reversible), I dislike even more making a half-assed decision. So rather than making a choice at all, my other choice would have been to not merge _either_ scheduler, and let people just continue to fight it out. Would that have made people happier? I seriously doubt it. Linus
Finally someone had the guts
Finally someone had the guts to call the PlugSched bluff of Con Kolivas. It was high time someone came with forward with competent technical arguments, after the self-hyping, self-pitying performance of Kolivas.
Yes: even the IO scheduler
Yes: even the IO scheduler maintainers are (partly) regretting that they allowed a plug-in model, and are suggesting to have one CPU scheduler. The author of the AS IO scheduler explained it best:
Anyway, moral of the story is that I think it would have been nice
if we hadn't proliferated IO schedulers, however in practice it
isn't easy to just layer features on top of each other, and also
keeping deadline helped a lot to be able to debug and examine
performance regressions and actually get code upstream. And this
was true even when it was globally boottine switchable only.
I'd prefer if we kept a single CPU scheduler in mainline, because I
think that simplifies analysis and focuses testing. I think we can
have one that is good enough for everyone.
A plug-in model like the linux kernel itself perhaps?
Linus Torvalds said "So I absolutely detest adding code for 'political' reasons."
BUT he is quite willing to keep Reiser4 out of the kernel for 'political' reasons.
Well Linus, when to we get to see Reiser4 in the kernel?
http://linux.50webs.org/installs/install-on-reiser4.htm
"Yes: even the IO scheduler maintainers are (partly) regretting that they allowed a plug-in model,..."
a plug-in model like the linux kernel itself perhaps?
a plug-in model like the
That is an eternal problem with you Linux bashers, getting the fundamental details right :>)
The core of the Linux kernel is not a plug-in model, it is a monolithic design. That is what Mr. Tanenbaum and Linus flamed each other about, eons ago. The "monolithic core design with select bits such as drivers and filesystems slightly modularized" approach of Linus won hands down. If you want a micro-kernel with everything modular and plugged-in, you should go to GNU/HURD perhaps.
That is not correct!
You CAN have plugins in a monolithic kernel! Monolithic design just means that you let drivers etc reside in kernel space (sharing memory with the kernel). Nothing says that just because you use plugins they have to be in user space!
Solaris is just as
Solaris is just as monolithic as Linux is, and _does_ have pluggable schedulers. This has _nothing_ to do with microkernels.
Bullshit. Linus ALWAYS has
Bullshit. Linus ALWAYS has the last say on a matter. Claiming that "he comes forward with competent
arguments" after doing argumentum ad hominem hits against Kolivas PRIOR to this post is a
lie.
But this by far does not mean that he is right when he claims the desktop profits the same if the
server gets a focus. Linux as an OS is still a huge mess. The distributions each try to solve
problems by adding more problems.
XGL wasnt done by Linus, yet its on the hype since... how long now... two years? It looks cool.
Some ideas are great to have. These ideas should get support, even from the Kernel OS devs!
(This includes the xorg devs, they need to get much more tightly in support with the
kernel guys.)
And ultimately - Its only to get on par with Vista and Mac!!!
And both are going to gain a better foothold on the web as well (with vista having only xp as a real
contester)
If you continue to defend the current development as great by attacking Con Kolivas in person, then
maybe you dont even want to start a discussion about the FOCUS the desktop OS gets - which is
the real pity.
So by calling you a silly
So by calling you a silly wanker the point I am about to make regarding your post will be, according to you, void? Nice way of discussing you have.
Linus does not have the 'last say'
You do not appear to have an overly accurate picture about how Linux maintainership works currently and how Linus interacts with other kernel maintainers and contributors. Linus often sends out his own patches to linux-kernel, for further review and discussion. Sometimes those patches get shot on the spot and Linus does not apply them. Sometimes they get picked up and others finish them up.
But to get to the point: Linus in large part defers to the maintainers of a given subsystem - even if he disagrees with a particular technical choice of a maintainer. If he disagrees very strongly he'll voice his opposition to the list, but otherwise he "lets the river flow" and he lets maintainers learn and evolve.
Linus indeed tends to be right most of the time, and to the lay outside observer this might be perceived as 'what Linus says, that happens', but he's right most of the time because he's simply a quite gifted fellow who has a good grasp of the technology and who has a good eye for picking the right people. Granted, he can also be overly straight with his opinion, so he is certainly not someone you could call a 'flamewar deterrent', as I'm sure you have witnessed it countless times here on KernelTrap -;-D
If Linus abused his position that would slowly but surely turn into a technological disadvantage and then someone with a better development model could eclipse the mainline kernel. This happened a number of times in the past 16 years, contributors (such as Alan Cox or Andrew Morton and others) were unhappy, flamed Linus hard, even forked the kernel and finally Linus changed the development model.
Contrast this with the current situation. You will not see a single Linux maintainer back up Con Kolivas's position. Why? Because Con has made an utter fool of himself. He was never part of the mainline kernel not because he was 'unjustly shut out', but because he chose to not be part of it. He hid on his ck list and generally ignored the mainline kernel. I just checked it and the logs show that he has less than two dozen commits in the mainline kernel out of more than 60 thousand commits in the past 2 years alone. That is not how you get to write and integrate major kernel features - you first have to hone your skills with the small stuff, you have to prove you can work well with the other contributors, before you are able to do the larger stuff. Sometimes very good people come 'out of nowhere' and do something major on the spot, but even those people work well with other contributors.
Then Con became impatient and tried to force-feed two major kernels features into perhaps one of the two most sensitive and hardest to hack kernel subsystems that exist (the scheduler and the virtual memory subsystem) and when maintainers resisted for entirely legitimate technological reasons he put up a big parting show and played to the peanut gallery over these relatively simple technical matters.
The fact that he was also ill while he tried to push those features did not help him remain cool and composed either. As a result he massively discredited himself, if in a few months or years he came back to develop the kernel again he'd have to work hard to undo the damage to his own reputation.
Con is a shining example of how not to contribute to the kernel.
testing purposes patches
Dear Linus
i am not a newbie, and the apps i test are not OpenGL games. so i would probably like
if Linus fits his jeans on, and publishes two patches to test which scheduler really works
for each case i test.
Examples of cases.
This cases have two scheduling processes mostly one, writing the mm, and the other in clean up of the mm. both related to the fair scheduler loads.
1.
Network heavy load, and filesystem random file access.
2.
truly memory cleanup and other memory invading process ackwards
3.
high access scheduling process (OpenGL) and low priority single heavy charge
4.
high priority kernel module loading, and standard filesystem-network load
5.
very high priority paging, and low priority input kernel modules
6.
asyncronic non standard filesystem access and syncronic network inbound charge
7.
deeply in-kernel modules with high priority, like nfs. and heavy low priority background user process-
Thanks
It was also about the developers' behaviour
Linus clearly stated that his decision was strongly influenced by the maintainers' behaviour.
You will find that hard to test for...
Now that i check about it
Now that i check about it TWICE, the SCHEDULER IS ULTRA IMPORTANT
because it's responsible of the switching betwen SMPs.
And also that i am using KVM i see that the Scheduler is responsible also
to an abusive high speed thread switching betwen the CPU 1 and CPU 2,
My explanation is :
FAIR SCHEDULER = Scheduler which gives the applications a initial but variable 'nice' value.
UNFAIR SCHED = Scheduler which gives the apps, and initial and unmodificable 'nice'value not
depending of other 'niced' apps.
someone can correct me?
not quite
No, this really has nothing to do with nice values. Fair means that each process gets an equal portion of the CPU. Nice values are used to give some processes more or less priority. Unfair (?) means that processes are weighted by additional characteristics.
Nice values are modifiable in both schedulers and aren't changed by the scheduler in either.
Of course the scheduler is important in any multitasking OS. You need to decide which task(s) to run. It needs to be quick, because you don't want to waste too much time deciding which task to run when you could be running that task.
I partly agree with Linus.
1 scheduler would be great but lets accept simple facts.
We need to try different models and balance.
Windows NT has 1 but the balance between server and client applications is adjusted. Client has lot higher processor access give to desktop applications. Server is a fair balance.
The question is how to do the bias Linux/Unix system was build around being fair.
Hmm
If we get pluggable schedulers, then we might as well get pluggable TCP/IP stack, etc and pluggable this and pluggable that.
I don't know which is best CFS or SD, of if none of them are better than the other, but either way, now we get CFS, and regardless if we would have got CFS or SD, it will still be much much better than the old scheduler.
So Con Kolivas didn't do it all in vain, even though his SD didn't get implemented in the mainline kernel. Because thanks to him, even though we don't get his SD, we still got a much better scheduler than the one we had.
This is exactly right - if
This is exactly right - if Con did not make his scheduler, Ingo would have never made his. Linus would have kept the bad schedular forever and Ingo would not have a place to copy from.
But... damage have been done. Good developers are chased away from the kernel. Anyhow, with Linus sold out, that may be a good thing. Everything GPL is rotten. There is really free software and it is not GPL.
Are you by any chance
Are you by any chance affiliated with the Time Cube fellow?
RE: Anonymous on GPL
You're perfectly able to relicense any patches you should write under your own terms, and distribute them thus to the public - the GPL doesn't remove your ability to grant additional licenses to your work. Of course, if you haven't actually written anything, and are complaining about the terms of others' work...
Yeah. Pluggable device
Yeah. Pluggable device drivers suck.
;->
Isn't choice for the
Isn't choice for the end-user the defining characteristic of open-source software?
I feel that it's Linus himself who made this into a political issue and now he's using this as an argument to avoid giving people the choice they deserve and forcing his personal view on everybody else. (I can fully understand now that Con decided to stop developing on the Linux kernel).
Re: Isn't choice for the
Please, stop the rhetoric. You can patch your kernel with Con's patches anytime you want. You still have the choice. It will just take a bit more of _your_ time.
Linus does not want a good
Linus does not want a good scheduler in the kernel. He has to keep it away because he is so ordered by those who provide a job for him. Is it so hard to see through his "thechnical" arguments which are nothing but politics. Linus also wants to piss off good, independent-minded developers and chase them away from the kernel. Not because he is megalomaniak, but because that is what his sponsors want. Linus' job is to subvert Linux. The astroturf-fest around the various "community" sites is busy supporting the said idiocy.
I am going BSD. Linux and GPL have become victims of the very same problems they promised to fix. I am sick of ridiculous politicas masked as "technical stuff".
Bye now. Hope it works out
Bye now. Hope it works out for you.
(Sorry for off-topic folks, hopefully we now return to the regularly scheduled programming.)
Linus =! consistent
I really don't understand Linus. Linus prevented SELinux from being included into the mainline kernel until Linux got a modular and pluggable framework in order to allow multiple approaches to be taken by different security groups.
And in the case of pluggable schedulers, Linus says its a bad idea.
Make up your mind Torvalds. You make no sense.
FWIW, OpenSolars has pluggable schedulers, allowing one to not only change the scheduler on the fly, but also on a per CPU basis. DragonFly is spitting distance away from having this capability, and the FreeBSD folks are working on this as well. Linux could __EASILLY__ have it now if not for this guy...
I know that Linus has always been an "Opinionated Bastard (TM)" but for crying out loud, at least try to be consistent.
There's a big difference...
We want a pluggable security model, because then different security tools can load their modules, and manage it in different ways. This is not something that would change for different usages.
We do NOT want pluggable schedulers, because then you'd have to choose a new one constantly.. "I'm going to play, I better load that scheduler" "I'm going to work on a picture, better load that scheduler" "I'm going to compile a lot, which scheduler do I need for that". It's just stupid, and makes the system MORE complicated for the user.
If OS, and the BSD's have it, they are starting ridiculous trends.
I'd not call pluggable
I'd not call pluggable schedulers rediculous. As has been stated by others, you do in fact want one generic scheduler for most needs and purposes, if for no other reason than to have one that is well known, widely used and tested. However, having one good default scheduler does not mean that a pluggable system for them is not required or undesireable.
There will always be casses where one would want or need to use a different scheduler as the 'main' schedular may be suboptimal in those cases. Also, having a pluggable framework as the base for the generic scheduler would allow work on specialized schedulers to go on in paralel with the main one, without affecting anything for the majority of people whos needs are met by the generic one.
The idea isn't to have a dozen different schedulers for the sake of having them; the idea of the pluggable framework is to simplify life for those who need something other than what suits most people, without making life difficult for the folks maintaining the generic one.
From what I've read, this isn't cauing the Solaris folks undue headaches, Matt Dillon sees little problem with the idea in DF, and the FreeBSD people... well, they'll get it right someday ;^)
If Linus is having difficulty with this sort of thing WRT Linux, then perhaps it's time for him to take a vacation, and let the good folks employed by any of the big corporations and other Linux supporting foundations to do things right for him.
(FWIW, I'm not anti-Linux, I just have issues with how Linus handles things, because the only thing he is consistent in is not taking the time to think things out).
If you need special
If you need special requirements, keep them as patches. No need to pollute an already huge kernel with more junk.
Just because it "isn't causing them headaches" doesn't mean it's necessary, or even desirable to fill more stuff into the kernel.
Linus' job is to say NO to unneeded complexity, especially in a sensitive area as the scheduling code.
Apache Kernel you say?
"If you need special requirements, keep them as patches. No need to pollute an already huge kernel with more junk."
The vast majority of Linux kernel bloat is from the drivers; far too many drivers implement the same basic thing over and over again (wireless ATM is a good example of that idiocy, with a good number of them implementing their own 802.11 layers).
Schedulers are small, and having to maintain patches without a pluggable framework with something even remotely resembling a stable API is work that could be avoided with a little thought on the developer's part.
"Linus' job is to say NO to unneeded complexity, especially in a sensitive area as the scheduling code."
If Linus put more thought into the kernel, and maybe excersised his atrophied coding muscles a bit, perhaps the kernel could finally be rid of a good chunk of the bloat and needless complexity.
About choices
I just want to give my two cents on the view of choices!
There is no technically valid point to why you should not be able to choose a scheduler during compile time except for possibly complexity and/or bloat. If you have a default scheduler that has good performance in all the general cases then it could be used as the default for everyone who does not have any preferences. At the same time if you need a scheduler with some special characteristic it SHOULD be possible to to use that one instead. Remember that there exist no scheduler that can handle all cases in the best possible way. You often need to decide which workloads should perform better then others.
I concur.
I concur.
Another "wise" decision by
Another "wise" decision by Linus "we don't need no kernel debugger" Torvalds. How surprising.
Pluggable infratstructure
I find it odd that Lignus rejects pluggability infrastructure for parts of the kernel that are clearly deficient and targets for future change. His desire for ones size fits all is laudible. But one size fits few is the reality.