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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox