From: Robert Love <rml@novell.com>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Con Kolivas <kernel@kolivas.org>,
Jeff Sipek <jeffpc@optonline.net>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@suse.de>
Subject: Re: [PATCH] Time sliced CFQ #2
Date: Mon, 06 Dec 2004 00:14:09 -0500 [thread overview]
Message-ID: <1102310049.6052.123.camel@localhost> (raw)
In-Reply-To: <CED75073-4743-11D9-9115-000393ACC76E@mac.com>
On Mon, 2004-12-06 at 00:00 -0500, Kyle Moffett wrote:
> What about this:
>
> nice = x; /* -20 to 20 */
> ioprio = y; /* -40 to 40 */
> effective_ioprio = clamp(x+y); /* -20 to 20 */
>
> This would allow tuning processes for unusual contrasts with the ioprio
> call.
> On the other hand, it would allow us to just brute force "adjust" a
> process with
> the nice command in the usual way without any changes to the "nice"
> source.
>
> I also thought of a different effective ioprio calculation that scales
> instead of clamping:
I think the complication of all of this demonstrates the overcomplexity.
I think we need to either
(1) separate the two values. we have a scheduling
priority (distributing the finite resource of
processor time) and an I/O priority (distributing
the finite resource of disk bandwidth).
(2) just have a single value.
Personally, I prefer (1). But (2) is fine.
What we want to do either way is cleanly separate the concepts in the
kernel. That way we can decide what we actually expose to user-space.
Robert Love
next prev parent reply other threads:[~2004-12-06 5:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 10:49 [PATCH] Time sliced CFQ #2 Jens Axboe
2004-12-04 16:39 ` Jeff Sipek
2004-12-05 18:58 ` Jens Axboe
2004-12-06 0:29 ` Jeff Sipek
2004-12-06 1:59 ` Con Kolivas
2004-12-06 2:23 ` Jeff Sipek
2004-12-06 2:34 ` Con Kolivas
2004-12-06 5:00 ` Kyle Moffett
2004-12-06 5:14 ` Robert Love [this message]
2004-12-06 7:19 ` Jens Axboe
2004-12-06 12:18 ` Helge Hafting
2004-12-06 12:24 ` Jens Axboe
2004-12-06 12:21 ` Kyle Moffett
2004-12-06 16:42 ` Robert Love
2004-12-06 17:42 ` P
2004-12-06 7:15 ` Jens Axboe
2004-12-06 7:13 ` Jens Axboe
2004-12-05 14:21 ` Ed Tomlinson
2004-12-05 15:18 ` Jens Axboe
2004-12-05 17:58 ` Ed Tomlinson
2004-12-06 9:31 ` Prakash K. Cheemplavam
2004-12-06 9:35 ` Jens Axboe
2004-12-06 11:48 ` Ed Tomlinson
2004-12-06 12:31 ` Prakash K. Cheemplavam
2004-12-06 13:27 ` [PATCH] Time sliced CFQ #3 Jens Axboe
2004-12-06 14:01 ` Søren Lott
2004-12-06 15:01 ` Jens Axboe
2004-12-06 15:45 ` Jens Axboe
2004-12-06 15:07 ` Prakash K. Cheemplavam
2004-12-06 23:30 ` Ed Tomlinson
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=1102310049.6052.123.camel@localhost \
--to=rml@novell.com \
--cc=axboe@suse.de \
--cc=jeffpc@optonline.net \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.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