public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



  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