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 12:59:43 +1100 [thread overview]
Message-ID: <41B3BD0F.6010008@kolivas.org> (raw)
In-Reply-To: <20041206002954.GA28205@optonline.net>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
Jeff Sipek wrote:
> On Sun, Dec 05, 2004 at 07:58:45PM +0100, Jens Axboe wrote:
>
>>It should be really easy to try some rudimentary prio io support - just
>>scale the time slice based on process priority. A few lines of code
>>change, and io priority now follows process cpu scheduler priority. To
>>work really well, the code probably needs a few more limits besides just
>>slice time.
>
>
> I started working on the rudimentary io prio code, and it got me thinking...
> Why use the cpu scheduler priorities? Wouldn't it make more sense to add
> io_prio to task_struct? This way you can have a process which you know needs
> a lot of CPU but not as much io, or the other way around.
That is the design the Jens' original ioprio code used which we used in
-ck for quite a while. What myself and -ck users found, though, was that
being tied to cpu 'nice' meant that most tasks behaved pretty much as
we'd expect based on one sys call.
I think what is ideal is to have both. 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.
Cheers,
Con
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
next prev parent reply other threads:[~2004-12-06 2:00 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 [this message]
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
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=41B3BD0F.6010008@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.