public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Pavel Machek <pavel@ucw.cz>,
	linux kernel mailing list <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: Tue, 02 Nov 2004 00:32:36 +1100	[thread overview]
Message-ID: <41863AF4.1040905@kolivas.org> (raw)
In-Reply-To: <20041101114124.GA31458@elte.hu>

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

Ingo Molnar wrote:
> my main worry with this approach is not really overhead but the impact
> on scheduler development. 

> no problem even under the current model, and it has happened before. We
> made the scheduler itself easily 'rip-out-able' in 2.6 by decreasing the
> junction points between the scheduler and the rest of the system. Also,
> the current scheduler is no way cast into stone, we could easily end up
> having a different interactivity code within the scheduler, as a result
> of the various 'get rid of the two arrays' efforts currently underway.

Do you honestly think with the current "2.6 forever" development process 
that this is likely, even possible any more?

Given that fact, it means the current scheduler policy mechanism is 
effectively set in stone. Do you think we can polish the current 
scheduler enough to be, if not perfect, good enough for _every_ situation?

Noone said that if we have a plugsched infrastructure that we should 
instantly accept any scheduler.

Regards,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  parent reply	other threads:[~2004-11-01 13:34 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
2004-11-01 13:32     ` Con Kolivas [this message]
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=41863AF4.1040905@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=alexn@dsv.su.se \
    --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