public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: David Lang <david.lang@digitalinsight.com>
Cc: Al Boldi <a1426z@gawab.com>,
	William Lee Irwin III <wli@holomorphy.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair   starvation free interactive cpu scheduler)
Date: Sat, 17 Mar 2007 22:44:33 -0500	[thread overview]
Message-ID: <45FCB5A1.2020702@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0703091604180.31392@qynat.qvtvafvgr.pbz>

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@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

  reply	other threads:[~2007-03-18  3:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-09 13:25 Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler) Al Boldi
2007-03-09 13:57 ` William Lee Irwin III
2007-03-09 20:43   ` Al Boldi
2007-03-09 22:18     ` Ryan Hope
2007-03-10  1:10       ` William Lee Irwin III
2007-03-10  0:06     ` David Lang
2007-03-18  3:44       ` Bill Davidsen [this message]
2007-03-10  0:16     ` William Lee Irwin III
2007-03-10  5:34       ` Al Boldi
2007-03-10  6:59         ` William Lee Irwin III
2007-03-10 16:47           ` Al Boldi
2007-03-10 19:31             ` William Lee Irwin III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45FCB5A1.2020702@tmr.com \
    --to=davidsen@tmr.com \
    --cc=a1426z@gawab.com \
    --cc=david.lang@digitalinsight.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox