login
Search
Con Kolivas [interview] posted a set of patches to the lkml offering a pluggable cpu scheduler framework. He began, "with the recent interest in varying the cpu schedulers in linux, this set of patches provides a modular framework for adding multiple boot-time selectable cpu schedulers. William Lee Irwin III [interview] came up with the original design and I based my patchset on that." The architecture independent framework is designed to allow new schedulers to be added by only touching three files, without adding overhead, and allowing you to compile in only the CPU scheduler(s) you need. Con explained, "this allows, for example, embedded hardware to have a tiny new scheduler that takes up minimal code space."
Designer of the 2.6 kernel's O(1) scheduler, Ingo Molnar [interview], had some reservations. He said, "my main worry with this approach is not really overhead but the impact on scheduler development. Right now there is a Linux scheduler that every developer (small-workload and large-workload people) tries to make as good as possible." This includes all corner cases, from the smallest embedded hardware to the largest NUMA hardware, with all their improvements benefiting the core CPU scheduler. Ingo added, "we want to make it _harder_ for specialized workloads to be handled in some 'specialized' way, because those precise workloads do show up in other workloads too, in a different manner. A fix made for NUMA or real-time purposes can easily make a difference for desktop workloads. Often 'specialized' is an excluse for a 'fundamentally broken, limited hack', especially in the scheduler world."
From: Con Kolivas [email blocked] To: linux kernel mailing list [email blocked] Subject: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework Date: Sun, 31 Oct 2004 00:32:34 +1000 With the recent interest in varying the cpu schedulers in linux, this set of patches provides a modular framework for adding multiple boot-time selectable cpu schedulers. William Lee Irwin III came up with the original design and I based my patchset on that. This code was designed to touch the least number of files, be completely arch-independant, and allow extra schedulers to be coded in by only touching Kconfig, scheduler.c and scheduler.h. It should incur no overhead when run and will allow you to compile in only the scheduler(s) you desire. This allows, for example, embedded hardware to have a tiny new scheduler that takes up minimal code space. This works by taking all functions that will be common to all scheduler designs and moving them from kernel/sched.c into kernel/scheduler.c. Then it adds the scheduler driver struct into scheduler.h which is a set of pointers to functions that will all have per-scheduler versions. include/linux/scheduler.h has the definitions for the scheduler driver structure kernel/sched.c remains as the default cpu scheduler in the same place to minimise the patch size and portability of the patch set. All variables of the task_struct that could be unique to a different scheduler are now in a private struct held within a union in task_struct. rt_priority and static_priority are kept global for userspace interface and for the possibility of adding run-time switching later on. The main disadvantage of this design is that there will (initially) be a lot of code duplication by different scheduler designs in their own private space. This will mean that if a new scheduler uses the same smp balancing algorithm then it will need to be modified to keep in sync with changes to the default scheduler. If, for example, you modified just the dynamic priority component of the current scheduler and left the runqueue and task_struct the same, you could make it depend on the default scheduler and point most functions to that one. However, the same disadvantage can be a major advantage. The fact that so much of the scheduler is privatised means that wildly different designs can be plugged in without any reference to the number of runqueues, frame schedulers could be plugged in, shared runqueues (eg on numa designs), and we could even keep new balancing in a "developing" arm of the scheduler that can be booted by testers and so on. What is left to do is add a per-scheduler entry into /sys which can be used to modify the unique controls each scheduler has, and write up some documentation for this and staircase. Anyway the patches will follow shortly, and then (not surprisingly) a port of the staircase scheduler to plug into this framework which can also be used as an example for others wishing to code up or port their schedulers. While I have tried to build this on as many configurations as possible, I am sure breakage will creep in given the type of modification so I apologise in advance. Patches for those who want to download them separately here: http://ck.kolivas.org/patches/plugsched/ Here is a diffstat of the patches rolled up. fs/proc/array.c | 2 fs/proc/proc_misc.c | 14 include/linux/init_task.h | 5 include/linux/sched.h | 39 - include/linux/scheduler.h | 83 ++ init/Kconfig | 37 + init/main.c | 10 kernel/Makefile | 3 kernel/sched.c | 1313 ++++++++-------------------------------------- kernel/scheduler.c | 1201 ++++++++++++++++++++++++++++++++++++++++++ mm/oom_kill.c | 2 11 files changed, 1599 insertions(+), 1110 deletions(-) Thanks to William Lee Irwin III for design help, Alex Nyberg for testing and a bootload of others for ideas and help with the coding. Cheers, Con
From: Pavel Machek [email blocked] Subject: Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework Date: Mon, 1 Nov 2004 00:33:13 +0100 Hi! > This code was designed to touch the least number of files, be completely > arch-independant, and allow extra schedulers to be coded in by only > touching Kconfig, scheduler.c and scheduler.h. It should incur no > overhead when run and will allow you to compile in only the scheduler(s) > you desire. This allows, for example, embedded hardware to have a tiny > new scheduler that takes up minimal code space. You are changing some_functions() into something->function() no? I do not think that is 0 overhead... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
From: Con Kolivas [email blocked] Subject: Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework Date: Mon, 01 Nov 2004 10:37:41 +1100 Pavel Machek wrote: > > You are changing > > some_functions() > > into > > something->function() > > no? I do not think that is 0 overhead... Indeed, and I am performing microbenchmarks to see what measurable overhead there is and so far any difference is lost in noise. Cheers, Con
From: William Lee Irwin III [email blocked] Subject: Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework Date: Sun, 31 Oct 2004 17:42:30 -0800 At some point in the past, Con Kolivas wrote: >> This code was designed to touch the least number of files, be completely >> arch-independant, and allow extra schedulers to be coded in by only >> touching Kconfig, scheduler.c and scheduler.h. It should incur no >> overhead when run and will allow you to compile in only the scheduler(s) >> you desire. This allows, for example, embedded hardware to have a tiny >> new scheduler that takes up minimal code space. On Mon, Nov 01, 2004 at 12:33:13AM +0100, Pavel Machek wrote: > You are changing > some_functions() > into > something->function() > no? I do not think that is 0 overhead... It's nonzero, yes. However, it's rather small with modern branch predictors; older microarchitectures handled this less well, which is probably why you expect a measurable hit. It may still have non-negligible performance effects on some legacy architectures, but I would not let that hold up progress. -- wli
From: Ingo Molnar [email blocked] Subject: Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework Date: Mon, 1 Nov 2004 12:41:24 +0100 * Pavel Machek [email blocked] wrote: > You are changing > > some_functions() > > into > > something->function() > > no? I do not think that is 0 overhead... my main worry with this approach is not really overhead but the impact on scheduler development. Right now there is a Linux scheduler that every developer (small-workload and large-workload people) tries to make as good as possible. Historically and fundamentally, scheduler development and feedback has always been a 'scarce resource' - the feedback cycle is (necessarily) long and there are alot of specialized cases to take care of, which slowly dribble in with time. firstly, if someone wants a different or specialized scheduler there's no problem even under the current model, and it has happened before. We made the scheduler itself easily 'rip-out-able' in 2.6 by decreasing the junction points between the scheduler and the rest of the system. Also, the current scheduler is no way cast into stone, we could easily end up having a different interactivity code within the scheduler, as a result of the various 'get rid of the two arrays' efforts currently underway. But i very much do not support making the 'junction points' at the wrong place. But more importantly, in the current model, people who care about 'fringe' workloads (embedded and high-end) are 'forced' to improve the core scheduler if they want to see their problems solved by mainline. They are forced to think about issues, to generalize problems and to solve them so that the large picture is still right. This worked pretty well in the past and works well today. It is painful in terms of getting stuff integrated but it works. Scheduler domains was and is a prime example of this concept in the works: load-balancing was a difficult issue that kept (some of) us uneasy for years and then a nice generic framework came along that replaced the old code, made both small boxes and large boxes possible. As a bonus it also solved the 'HT scheduling' issue almost for free. Sched-domains is nice for both the low-end and the high-end - it enables 512 CPU single-system-image systems supported by (almost-) vanilla 2.6 kernel. What more can we ask for? I am 100% sure that we'd not have sched-domains today had we gone for a 'plugin' model say 2-3 years ago. It's always hard to predict 'what if' scenarios but here's my guess: we'd have a NUMA scheduler, a separate SMP scheduler, a number of UP schedulers and embedded schedulers, and say HT would be supported in different ways by the SMP and NUMA schedulers. or to give another example: we emphatically do not allow 'dynamic syscalls' in Linux, albeit for years we've been hammered with how enterprise-ready Linux would be from them. In reality, without 'dynamic syscalls' all the 'fringe functionality' people have to think harder and have to integrate their stuff into the current syscalls/drivers/subsystems. the process scheduler is i think a similar piece of technology: we want to make it _harder_ for specialized workloads to be handled in some 'specialized' way, because those precise workloads do show up in other workloads too, in a different manner. A fix made for NUMA or real-time purposes can easily make a difference for desktop workloads. Often 'specialized' is an excluse for a 'fundamentally broken, limited hack', especially in the scheduler world. I believe that by compartmenting in the wrong way [*] we kill the natural integration effects. We'd end up with 5 (or 20) bad generic schedulers that happen to work in one precise workload only, but there would not be enough push to build one good generic scheduler, because the people who are now forced to care about the Linux scheduler would be content about their specialized schedulers. Yes, it would be easier to make a specialized scheduler work well in that precise workload (because the developer can make the 'this is only for this parcticular workload' excuse), and this approach may satisfy the embedded and high-end needs in a quicker way. So i consider scheduler plugins as the STREAMS equivalent of scheduling and i am not very positive about it. Just like STREAMS, i consider 'scheduler plugins' as the easy but deceptive and wrong way out of current problems, which will create much worse problems than the ones it tries to solve. Ingo ( [*] how is this different from say the IO scheduler plugin architecture? Just compare the two, it's two very different things. Firstly, the timescale is very different - the process scheduler cares about microseconds, the IO scheduler's domain is milliseconds. Also, IO scheduling is fundamentally per-device and often there is good per-device workload isolation so picking an IO scheduler per queue makes much more sense than say picking a scheduler per CPU ... There are other differences too, such as complexity and isolation from the rest of the system. )
design improvement vs. dilution of one scheduler
Con's design is an improvement to how the scheduler integrates with the rest of the kernel. Such improvements help compartmentalize bugs, simplify the interface, and lower the learning curve new developers have to climb when learning a subsystem.
Con's patch removes the spaghetti of the scheduler by narrowing the interface to a single file and allowing for 'N' schedulers - as opposed to having a mess of $ifdef's throughout other files.
Ingo is concerned that by simply *allowing* more than one scheduler, developers will immediately fork & tweak, thus diluting the effort going into the "tried and true" scheduler. This argument doesn't hold water - Con's patch is simply an improvement to the interface between the kernel and the scheduler, one that was previously so entrenched that only one scheduler could cleanly exist. This does not remove the ability to have a single tried and true scheduler in the kernel.
Think of it this way - should the Linux community have worried about multiple forks the day the Linux kernel was modified to separate architecture specific code from kernel functionality, such ports to different architectures would be allowable in a single source tree? - No. It was a design milestone on the road to becoming a robust operating system.
- KRC
is good
Ingo is wrongly concerned: pluggable schedulars sound like a fantastic idea, because various server, client or embedded solutions may demand specific types of scheduling arrangements. It may be provoke experimentation and innovation. Of course, the main Linux distributions will only ever carry high quality schedulars, even if there are people who develop dud and useless ones.
Definite merge
Indeed. And when Con gets around to making a /sys/ interface
Seems to me like some people got this plugsched thing the wrongto change schedulers on the fly, it'll be even easier for Ingo
to choose which schedulers are merged.
way around; instead of having a good environment to develop and
test for, they see it as a shitstorm front on the horizon... If nothing else, this could serve as a means to benchmark schedulers
without going through a lot of patching and compiling.
This is can be called expedited natural selection ;) And I emphasize again, there's no reason to imagine this will
drop the quality of kernel schedulers.
General or specific
Ingo appears to be concerned that developers will concentrate on creating schedulers that will perform well to meet a specific need, but won't perform well when used in any other different load/configuration setup.
He also states that by improving the general scheduler, that can handle anything, sometimes you get benefits in areas that the original author had not intended, you will lose this if each developer concentrates on solving a very specific problem.
Swapping schedulers on the fly might lead to strange side-effects, such as the algorithm continually toggling between two schedulers e.g. under load x scheduler A might be best; then if the load changes scheduler B might be better suited and switched in. The difference between the two algorithms may mean that scheduler B causes the load to look like load x again, so scheduler A is selected, which would cause it to swap to scheduler B again....
One scheduler that can handle the complete spectrum of load cases means that you won't end up with load cases 'falling' into the gaps between the different schedulers' sweet-spots and performing disportionately badly to load cases either side of it.
I don't think that keeping the code deliberately messy/complicated to put people off experimenting with it is a sensible thing to do. It is almost like saying that if they don't understand the current mess then they shouldn't alter it - this could prevent someone from improving the current algorithm. However, I agree that having a unified scheduler algorithm keeps performance predictable.
I agree with Ingo
However, if we make it easier for people new to kernel development to play around with these important components perhaps we can gather fresh new ideas from their toy projects that could be integrated into the O(1) scheduler and improve overall performance of the system. Personally I would add this patch and all close-to-production-quality schedulers as experimental components of the system for developers only. One of those schedulers might be useful for systems like embedded devices that have limited scheduler requirements but more concerns about memory footprint and simplicity.
IMO we're looking for new concepts, new ideas, and I don't see a better way to get them than to make it easier for people to hack.
Want to encourage developement? Push what you know about the system into the hands of those who don't know and give them pretty colorful documentation, charts, graphs, audio and video media that helps them wrap their puny little brains around the bigger picture. This stuff can be fun, but its our job (those of us who know this stuff) to make learning fun for everyone else. This requires some creativity and love. You love what you do? Show us why its so cool. We'll help spread that message on to others, and so on.. Eventually one day some new kid will be able to download a video that explains in detail how the scheduler is designed, complete with entertaining sound track and colorful CG showing logical concepts along with code examples. Er, well, that's what I think. But I write Perl. :(
RE: I agree with Ingo
Perhaps I wasn't very clear: I _am_ in favour of this patch.
I don't agree with the idea of having unecessarily complicated code to ensure that there is a rite of passage before you are allowed in the scheduler cliche, that is elitist and stops people from understanding and experimenting.
As you point out, when the algorithms are clearly and cleanly explained it can give someone without preconceptions the insight to create something new and interesting.
I still agree with Ingo that having lots of different selectable schedulers available in Linux is not a good idea, however this should not stop people developing and testing new schedulers.
Keeping alternative schedulers in patchsets means that they can be developed alongside the current scheduler, and when one is at a point where it out performs the mainline scheduler the tidied code would make it trivial to swap them.
D'oh!
s/cliche/clique/ (and yes, I did proof read it!)
Some ideas as to why this is good
Having a pluggable architecture might also help for the next generation scheduler. Next time a scheduler rewrite is needed, it might be possible to start from scratch, instead of copying/forking. It's always good to start with a piece of blank paper.
It's also a very good thing for teaching. Take your students and ask them to write a scheduler for the system. That's great! You definitively can't do that with a close system.
Finally I wonder if there would be some interest in having a different scheduler active at different 'system times'. E.g. when you boot / shutdown.
I am all in favor of this design improvement.
Unlike what was said the "Gen
Unlike what was said the "General or Specific" post, I don't believe
That said, I think the forthcoming (if Con's still interested afterthe idea ever was to have the kernel predict which scheduler suits
the current use best.
people wantonly bashing his work) /sys/ interface would allow this. Just set something in the crontab :) I just hope someone tells Ingo that this should really be merged;
someone with a bit more power than little old me :)
The CK patchset
The CK patchset is MASSIVLY better on a multimedia desktop, I can load multiple DVD iso torrents while watching HD video in mplayer, and I wont drop a frame. Ive allways has an insane desire for this capability, and the CK patchset delievers. Id hope the mainline kernel adopts some of this stuff. It solves real problems now, and is NOT a dirty hack. One schedular for all workloads is proably not the way to be.
ck experience
I can load multiple DVD iso torrents while watching HD video in mplayer
I can do more than that with the vanilla kernel, it's really not that impressive. Any halfway decent scheduler should be able to handle network activity plus moderate disk I/O and still be able to play video smoothly (provided you have modern hardware).
One thing I *have* noticed about the -ck patchset is significantly reduced stability. The only times I've had kernels randomly hard lock-up under load has been when I've been using CK kernels. Even if the performance was better (which it wasn't) it wouldn't be worth the potential data loss.
ck experience
the ck kernel and gentoo ricer goes together well. I agree none of this is really impressive. When can we have the scheduling and smooth work environment the freebsd people taste?
you are a moron
im far from someone spending days compiling everything with wack options, i didnt want mplayer to skip for any reason, it will on 2.6.9 vanilla, it wont with ck, real problem, real solution.
no ricing
FreeBSD?
FreeBSD's SCHED_ULE scheduler, while esentially a reimplementation of Ingo's O(1) scheduler (queueing infrastructure, anyway) is not at all stable so it is not used.
FreeBSD also have plenty of reports (that I've seen) of bad interactivity.
FreeBSD?
but wouldnt that be covered by the GPL?
the code is, the algorithm is
the code is, the algorithm is not
Nice troll attempt, but, as a
Nice troll attempt, but, as anyone who has paid any attention to the development of FreeBSD 5.x is aware, the scheduler has been and still is one of the contentious and not-yet-solved (as in providing a good interactive user experience under heavy load) issues. Skim the -current mailing list for confirmation.
As for the -ck patchset, under 2.4.x it provided a marked improvement for interactive use (and to no ill effect stability-wise on my machines), but since moving to 2.6.x (where x is currently 4) I've had absolute no need for it (and I'm a heavy mplayer/bittorrent user).
no
I dont see how you can, my system , an athlon 2800+ with 512 ram on nforce, will cause mplayer even xmms to skip if im doing something very intense, or more than one intense thing. i dont think your telling the truth here, or you maybe using manual nice levels, witch i need to use when im doing this stuff on ck
you may not see a difference, but audio folks do
despite the all the debunking, latencies are still a problem in the stock vanilla kernel. just because you don't see any problems, such as during multitasking doesn't mean the problem doesn't exist (perhaps you may in fact encounter it on a lower end system, in which case such patches will probably make a noticable difference).
real time audio work still REQUIRE such patches like those by andrew morton and robert love for low latency and preemption. so until the kernel out-of-box can handle such types of loads then i don't think it's fair to declare this type of work as making no difference.
stop it with low latency, you
stop it with low latency, you can play audio file correctly with a commodity (here meaning non real-time) kernel even when the cpu is under heavy load. The point is that audio files player should be given more priority than gcc for example (question of quality of service). By using a corresponding scheduling policy, you should be able to play nicely audio files while running a make -J 20. There has been a lot of research work for multimedia operating systems and quality of service. One of the main conclusions is that the os must be able to differenciate the services it is running. This can 'simply' be implemented with hierarchies of schedulers for each ressources (one for cpu, one for i/o, ...).
yes
i only had one SINGLE interactivity problem with staircase, and that was winex, and winex sucks anyway, nothing else i have been doing made stuff go wrong, my mplayer never skipped, neither has my xmms done, ever, with staircase.
agree
Same here. And winex has only recently begun shifting towards the 2.6 kernel after 2.6 optimization won the user vote. I am using -ck simply because I tested all the major schedulers and found staircase to perform by far the best. My system simply feels (and is) more responsive, especially under load.
I don't have this problem
On RedHat 9 while encoding a DVD on the fly and copying 1G of data through scp I can still stream an MPEG4/ogg/ogm video over the 'net without any skipping. Audio is never a serious problem. And I'm using a 2600+ with 256MB of RAM, nforce.
I should note that the DVD encode is nice -n 19.
It might skip if I'm compiling something, but not if I nice that too. If you're not being nice to your system, any system, it will stop responding. These computers just do what they're told, right? Its up to us users to learn how not to kill them.
No, not interactive task should not be a problem
But currently they are: at work I have RedHat Enterprise9 on a beefy PC but today an admin updated a bunch of RPM while I was working, at the beginning my PC *froze* for ~1 seconds, I thought that there was a network problem!
After it was a little better but during all the RPMs installation the PC was not very useable.. which is NOT normal: a non-interactive task such a script installing a bunch of RPMs should not compete with 'normal' user usage.
What if...
What if you're using the console on a server? Do you want it to slow down its network connections while it launches your web browser?
Its important for us 'normal' users to understand we're working with industrial software that will do what we tell it to. If we're not careful, if we go around installing rpms on user's systems without using nice they will notice a slight interruption in performance. This year, anyway. Next year, when we're all using multi-core CPUs we'll be laughing at all the time we wasted commenting about this stuff.
Actually that's an argument for having two scheduler
As you said, the behaviour expected on a workstation is different than on a server, so maybe we should have two different scheduler one for server one for workstation?
Or one scheduler but with a configuration parameter.
Maybe multi-core CPU will help, but I kind of doubt it: in this case the access to the disk was the bottleneck not the CPU..
Why the disk is a bottleneck on a PC with 1.5GB of RAM is beyond me: my desktop should fit totally in RAM without any need of accessing the disk..
Reports?
What did you find when you traced these lock-ups?
Yeah, I think I rest my case...[1] Point being, the first bad experience turns users away and thegood experience never gets noted. Also, people don't want to see
why they had bad experience with, say, -ck, because they're down
with the vanilla kru. This naturally means that -ck will get a bad reputation it doesn't
deserve. I have to admit, I had one lock-up with 2.6.9-cko1, not
-ck, and after enabling debug info, it never locked again. Then
-ck2 came out. Anyway, this must be the mother of all digressions. The point lies
in whether or not plugsched is a good thing. The concept is and
the code seems to be. Regardless of other peoples' subjective
opinions about what other stuff Con has produced. There shouldn't
even be a problem here. [1] If you actually tried to trace the problem, I am sorry. You did
more than a lot of other people would.
tracing
Expecting a user to do kernel debugging is unreasonable. The -CK tree is touted as a user solution to multimedia work when it clearly has major problems and seemingly little QA work.
One-sided coin?
That doesn't sound right to me.
The implied QA work is still done by the community and someof the community is about something else than multimedia work.
Surely there
are a lot of people out there capable of reporting a bug, who would
also use -ck because it's better. Therefore IMO your argument is flawed. Is there really no single advanced-enough Linux user out there
who'd use nothing but vanilla, or maybe -mm?-) I'd then tend to
count myself as the sole one...
ricer madness
At what point do you draw the line of becoming a ricer? I think a windows gamer may call any linux user a ricer.
Hmmm
Probably at the point where irrational modifications are justified using flawed, anecdotal evidence for putative performance gain. Like the idea that compiling everything yourself magically gives you a giant performance boost. Or using a flawed, unstable kernel tree gives you MASSIVELY superior multimedia performance.
I'm a Gentoo user, by the way. :)
ricer
Please explain this strange word. People talk about it on Slashdot too. Must be some cultural phenomenon I haven't heard of..?
Re: ricer
It was borrowed from street "racing" (and I use that term loosely). You know how 17 year olds and guatemalans bolt 18 inch spoilers and chrome painted hubcaps onto 100 horsepower Hondas? Put fake badges, fire extinguishers, and obnoxious decals on an '87 Accord? $2500 rims on a $3000 shitbox? They're the original "ricers" - they try to make a Japanese econo-car look fast. These cars used to be referred to as "rice burners," hence their enthusiastic owners are "ricers."
Some enthusiastic Gentoo users are referred to as "ricers" because they think -march=athlon-xp will turn their Dell into a Beowulf cluster.
"Some enthusiastic Gentoo use
"Some enthusiastic Gentoo users are referred to as "ricers" because they think -march=athlon-xp will turn their Dell into a Beowulf cluster."
I can't see how that could be, since Dell doesn't use Athlons ;).
That said: I use Gentoo, and I love it. And no, optimizations wont turn your computer in to a supercomputer. They CAN give you benefits in certain apps and they CAN improve the overall performance of the system. But 98% of the time the difference in not humungous.
And I find that flaming in Slashdot about "Gentoo Zealots" to be pretty interesting. I constantly see people attack Gentoo and it's users, but I very rarely see someone praising Gentoo or being an "obnoxious Gentoo-fanboy". And I find that to be pretty sad, considering that the Gentoo-community is just about the most helpful bunch of people I have seen. Yet some people have nothing better to do than the flame those nonexistant "Gentoo-zealots".
Hell, it has got so bad that all it takes is to mention casually that "I emerged it yesterday" or something like that. In about 5 minutes, you will have people calling you a "Gentoo zealot" or "fanboy". But if someone praises apt-get or urpmi or up2date, nobody gives a damn. Double standards? I think so.
CK
The CK patchset is awesome, the CFQ is awesome, staircase cpu scheduler and CK's other enhancements really make the multimedia linux desktop experience a good time. Thank god you idiots talking sh*t, is just that.
Ingo's point is valid, but if
Ingo's point is valid, but if it makes the turn around time for developing a better scheduler smaller, then I think it's a good thing.
Of course, I'm not exactly against having a scheduler optimized for one particular duty. If nothing else, it would provide a baseline to compare against.
Not required for the moment i don't think
This is a pretty nice thing and yes it LOOKS like the best thing since sliced and even standard bread but it isn't time for it yet.. The Linux scheduler is undergoing alot of work right now and having several scheduler people fighting to keep up is not the best plan of action.
Furthermore I feel that once the general purpose scheduler gets fully patched up to its maximum ability then we can use this architecture or maybe a slightly altered one perhaps to allow additions of other more specialized schedulers.
-DaMouse
3 years later ...
You can't hide on the Internet. Ingo Molnar up to his usual tricks of denying Con at every turn. Just more evidence that he is a thief of ideas and promotes his own glory above all.