public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kasper Sandberg <lkml@metanurb.dk>
To: Ingo Molnar <mingo@elte.hu>
Cc: Pavel Machek <pavel@ucw.cz>, Con Kolivas <kernel@kolivas.org>,
	LKML Mailinglist <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Peter Williams <pwil3058@bigpond.net.au>,
	William Lee Irwin III <wli@holomorphy.com>,
	Alexander Nyberg <alexn@dsv.su.se>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH][plugsched 0/28] Pluggable cpu scheduler framework
Date: Mon, 01 Nov 2004 14:08:22 +0100	[thread overview]
Message-ID: <1099314502.14135.9.camel@localhost> (raw)
In-Reply-To: <20041101114124.GA31458@elte.hu>

On Mon, 2004-11-01 at 12:41 +0100, Ingo Molnar wrote:
<snip>
> 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.

i see your point, and i agree its not very nice to have specialized
schedulers for particular workloads only. however, as i see it,
plugsched doesent have any direct overhead, and plugsched doesent remove
the ability to develop on one allround scheduler, which tries to handle
all workloads good. however plugsched does give the opportunity to
create specialized schedulers, and as i see it not, staircase does a
better job in handling allround workloads(atleast for me). and it
certainly do make stuff easier.

> 
> 	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. )
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2004-11-01 13:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-30 14:32 [PATCH][plugsched 0/28] Pluggable cpu scheduler framework Con Kolivas
2004-10-31 23:33 ` Pavel Machek
2004-10-31 23:37   ` Con Kolivas
2004-11-01  1:42   ` William Lee Irwin III
2004-11-01 11:41   ` Ingo Molnar
2004-11-01 13:08     ` Kasper Sandberg [this message]
2004-11-01 13:32     ` Con Kolivas
2004-11-01 14:23       ` Nick Piggin
2004-11-01 17:54     ` Jesse Barnes
2004-11-02 21:28     ` Matthias Urlichs
2004-11-02 22:30       ` Peter Chubb

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=1099314502.14135.9.camel@localhost \
    --to=lkml@metanurb.dk \
    --cc=akpm@osdl.org \
    --cc=alexn@dsv.su.se \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pavel@ucw.cz \
    --cc=pwil3058@bigpond.net.au \
    --cc=torvalds@osdl.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