linux-kernel - Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <45FCB5A1.2020702@tmr.com>
Date:	Sat, 17 Mar 2007 22:44:33 -0500
From:	Bill Davidsen <davidsen@....com>
To:	David Lang <david.lang@...italinsight.com>
CC:	Al Boldi <a1426z@...ab.com>,
	William Lee Irwin III <wli@...omorphy.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair  
  starvation free interactive cpu scheduler)

David Lang wrote:
> On Fri, 9 Mar 2007, Al Boldi wrote:
> 
>>
>>> My preferred sphere of operation is the Manichean domain of faster vs.
>>> slower, functionality vs. non-functionality, and the like. For me, such
>>> design concerns are like the need for a kernel to format pagetables so
>>> the x86 MMU decodes what was intended, or for a compiler to emit valid
>>> assembly instructions, or for a programmer to write C the compiler
>>> won't reject with parse errors.
>>
>> Sure, but I think, even from a technical point of view, competition is 
>> a good
>> thing to have.  Pluggable schedulers give us this kind of competition, 
>> that
>> forces each scheduler to refine or become obsolete.  Think evolution.
> 
> The point Linus is makeing is that with pluggable schedulers there isn't 
> competition between them, the various developer teams would go off in 
> their own direction and any drawbacks to their scheduler could be 
> answered with "that's not what we are good at, use a different 
> scheduler", with the very real possibility that a person could get this 
> answer from ALL schedulers, leaving them with nothing good to use.
> 
Have you noticed that currently that is exactly what happens? If the 
default scheduler doesn't handle your load well you have the option of 
rewriting it and maintaining it, or doing without, or tying to fix your 
case without breaking others, or patching in some other, non-mainline, 
scheduler.

The default scheduler has been around long enough that I don't see it 
being tuned for any A without making some B perform worse. Thus multiple 
schedulers are a possible solution.

They don't need to be available as runtime choices, boot time selection 
would still allow reasonable testing. I can see myself using a compile 
time option and building multiple kernels, but not the average user.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/