Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* Willy Tarreau <[email protected]> wrote:

Ingo could have publicly spoken with them about his ideas of killing the O(1) scheduler and replacing it with an rbtree-based one, [...]

yes, that's precisely what i did, via a patchset :)

[ I can even tell you when it all started: i was thinking about Mike's
  throttling patches while watching Manchester United beat the crap out
  of AS Roma (7 to 1 end result), Thuesday evening. I started coding it
  Wednesday morning and sent the patch Friday evening. I very much
  believe in low-latency when it comes to development too ;) ]

(if this had been done via a comittee then today we'd probably still be trying to find a suitable timeslot for the initial conference call where we'd discuss the election of a chair who would be tasked with writing up an initial document of feature requests, on which we'd take a vote, possibly this year already, because the matter is really urgent you know ;-)

[...] and using part of Bill's work to speed up development.

ok, let me make this absolutely clear: i didnt use any bit of plugsched - in fact the most difficult bits of the modularization was for areas of sched.c that plugsched never even touched AFAIK. (the load-balancer for example.)

This sounds like your new scheduler intends to increase the coupling between scheduling and load balancing. I think that this would be a mistake and lead (down the track) to spiralling complexity as you make changes to the code to address the corner conditions that it will create.


Plugsched simply does something else: i modularized scheduling policies in essence that have to cooperate with each other, while plugsched modularized complete schedulers which are compile-time or boot-time selected, with no runtime cooperation between them. (one has to be selected at a time)

You can't really have more than one scheduler operating in the same priority range on the same CPU as they will be fighting each other trying to achieve their separate and not necessarily compatible (in fact highly likely to be incompatible) aims. Multiple schedulers on the same CPU have to have a pecking order just like SCHED_OTHER and real time policies. It wouldn't be hard to prove that SCHED_RR and SCHED_FIFO is a problem in waiting if ever someone tried to use them both on a highly real time system.


(and i have no trouble at all with crediting Will's work either: a few years ago i used Will's PID rework concepts for an NPTL related speedup and Will is very much credited for it in today's kernel/pid.c and he continued to contribute to it later on.)

(the tree walking bits of sched_fair.c were in fact derived from kernel/hrtimer.c, the rbtree code written by Thomas and me :-)

	Ingo

Are your new patches available somewhere for easy download or do I have to try to dig them out of the mailing list archive? Or could you mail them to me separately? I'm keen to see how you new scheduler proposal works.

Thanks
Peter
--
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux