Discussion continues regarding the choice to merge the CFS scheduler [1] into the upcoming 2.6.23 kernel. A recent thread looked at the possibility of having merged the plugsched [2] code to allow for both the CFS and SD schedulers [3] to coexist in the mainline kernel at the same time, thereby avoiding the recent flamewars. Linus Torvalds pointed to the ManagementStyle documentation [4] 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
Related Links:
- Archive of above thread [5]