From: Con Kolivas <kernel@kolivas.org>
To: Jeff Sipek <jeffpc@optonline.net>
Cc: Jens Axboe <axboe@suse.de>, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Time sliced CFQ #2
Date: Mon, 06 Dec 2004 13:34:51 +1100 [thread overview]
Message-ID: <41B3C54B.1080803@kolivas.org> (raw)
In-Reply-To: <20041206022338.GA5472@optonline.net>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
Jeff Sipek wrote:
> On Mon, Dec 06, 2004 at 12:59:43PM +1100, Con Kolivas wrote:
>>First the ioprio should be set to
>>what the cpu 'nice' level is as a sort of global "this is the priority
>>of this task" setting. Then it should also support changing of this
>>priority with a different call separate from the cpu nice. That way we
>>can take into account access privileges of the caller making it
>>impossible to set a high ioprio if the task itself is heavily niced by a
>>superuser and so on.
>
>
> This sounds very reasonable. How would a situation like this one get
> handeled:
>
> nice = x
> io_prio = y
>
> where x!=y
>
> then, user changes nice. Does the nice level change alone? If so,
> providing some "reset to nice==io_prio" capability would make sense, no?
I think when nice is changed, ioprio needs to be changed with it as a
sane default action. I suspect that most of the time people will not use
the separate ioprio call, but using 'nice' is a regular linuxy thing to
do. Ideally we make ioprio part of the 'nice' utility and we specify
both at the same time. Something like:
nice -n 5 -i 20 blah
Cheers,
Con
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
next prev parent reply other threads:[~2004-12-06 2:35 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 [this message]
2004-12-06 5:00 ` Kyle Moffett
2004-12-06 5:14 ` Robert Love
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=41B3C54B.1080803@kolivas.org \
--to=kernel@kolivas.org \
--cc=axboe@suse.de \
--cc=jeffpc@optonline.net \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.