Hi Andi, On Wed, Jul 11, 2007 at 11:16:38PM +0200, Andi Kleen wrote:I'm going to change topic big time because your sentence above perfectly applies to the O(1) scheduler too. It's not like process schedulers are sacred and there shall be only one, while I/O schedulers and packet schedulers are profane and there can be many of them. FWIW IMHO the right way would have been to make the new scheduler pluggable and switchable at runtime, too bad it was ripped off instead. The difficulty of making the scheduler pluggable isn't really enormous, there have been patches floating around to achieve it, some I even deal with them myself once. The only positive side of being forced to CFS I can imagine, is that more testing will make it more stable and more tuned more quickly. But I'm fairly certain Ingo's good enough to achieve without it, perhaps with a few more weeks. Personally I very much like the unfariness of O(1), I'm afraid CFS will overschedule under a certain number of workloads in its attempt to provide a complete fair queieing at all costs, and it won't deal with the X server as nicely as O(1), but I may as well be wrong. The only thing I'm more sure about is that the computational complexity is higher, and that reason alone is a good technical reason to provide both and let the java folks stick with O(1) if they want. -
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Arjan van de Ven | [Announce] Development release 0.1 of the LatencyTOP tool |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 020/196] IDE: Convert from class_device to device for ide-tape |
git: | |
| Tantilov, Emil S | RE: [PATCH] net: sk_alloc() should not blindly overwrite memory |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
