From: Valdis.Kletnieks@vt.edu
To: "Marc E. Fiuczynski" <mef@CS.Princeton.EDU>
Cc: Peter Williams <pwil3058@bigpond.net.au>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Con Kolivas <kernel@kolivas.org>, Chris Han <xiphux@gmail.com>
Subject: Re: [ANNOUNCE][RFC] plugsched-2.0 patches ...
Date: Thu, 20 Jan 2005 12:51:57 -0500 [thread overview]
Message-ID: <200501201751.j0KHpvdQ030760@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Thu, 20 Jan 2005 11:14:48 EST." <NIBBJLJFDHPDIBEEKKLPGELGDHAA.mef@cs.princeton.edu>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
On Thu, 20 Jan 2005 11:14:48 EST, "Marc E. Fiuczynski" said:
> Peter, thank you for maintaining Con's plugsched code in light of Linus' and
> Ingo's prior objections to this idea. On the one hand, I partially agree
> with Linus&Ingo's prior views that when there is only one scheduler that the
> rest of the world + dog will focus on making it better. On the other hand,
> having a clean framework that lets developers in a clean way plug in new
> schedulers is quite useful.
>
> Linus & Ingo, it would be good to have an indepth discussion on this topic.
> I'd argue that the Linux kernel NEEDS a clean pluggable scheduling
> framework.
Is this something that would benefit from several trips around the -mm series?
ISTR that we started with one disk elevator, and now we have 3 or 4 that are
selectable on the fly after some banging around in -mm. (And yes, I realize that
the only reason we can change the elevator on the fly is because it can switch
from the current to the 'stupid FIFO none' elevator and thence to the new one,
which wouldn't really work for the CPU scheduler....)
All the arguments that support having more than one elevator apply equally
well to the CPU scheduler....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
next prev parent reply other threads:[~2005-01-20 17:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 1:23 [ANNOUNCE][RFC] plugsched-2.0 patches Peter Williams
2005-01-20 1:58 ` Kasper Sandberg
2005-01-20 16:14 ` Marc E. Fiuczynski
2005-01-20 17:51 ` Valdis.Kletnieks [this message]
2005-01-21 14:11 ` Jens Axboe
2005-01-21 16:29 ` Marc E. Fiuczynski
2005-01-21 16:43 ` Con Kolivas
2005-01-21 21:20 ` Peter Williams
2005-01-21 2:38 ` Peter Williams
2005-01-21 2:50 ` Marc E. Fiuczynski
2005-01-21 15:16 ` [ckrm-tech] " Shailabh Nagar
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=200501201751.j0KHpvdQ030760@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mef@CS.Princeton.EDU \
--cc=pwil3058@bigpond.net.au \
--cc=xiphux@gmail.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;
as well as URLs for NNTP newsgroup(s).