From: Jens Axboe <axboe@suse.de>
To: Jeff Sipek <jeffpc@optonline.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel@kolivas.org, nickpiggin@yahoo.com.au
Subject: Re: IO Priorities
Date: Mon, 13 Dec 2004 15:38:10 +0100 [thread overview]
Message-ID: <20041213143809.GO3033@suse.de> (raw)
In-Reply-To: <20041213142217.GA22853@optonline.net>
On Mon, Dec 13 2004, Jeff Sipek wrote:
> Hello all,
> About a week ago, I said I would try to implement IO priorities.
> I tried. I got the whole thing done, but there is one major problem - it
I did too, did you see my patch?
> doesn't work the way it is supposed to. For example, I wrote a little
> shell script that calls:
>
> time dd if=/dev/zero of=dump bs=4096 count=200000
>
> It calls it twice, once as the highest priority (0) and once as the
> lowest priority (39). The only difference (besides the output file) is
> the io priority. Nice values are _not_ connected with io prio (at least
> not yet.) The only thing that the io_prio affects is the coefficient in
> front of the cfq time slice length (see patch). The interesting thing
> that happens is that sometimes the lower priority process finishes before
> the higher priority one - even though the time slices are WAY way different
> in size (1ms and 223ms). Con Kolivas told me that he experienced the same
> odd behaviour when he implemented io priorities on top of deadline.
Well, for this specific case, I'd suggest you check out how much of the
write out actually happens in context of that process. Often you end up
with pdflush(es) doing the process dirty work, and the io priorities
aren't inherited across that boundary.
> -static int cfq_slice_sync = HZ / 10;
> -static int cfq_slice_async = HZ / 25;
> +static int cfq_slice_sync = HZ / 1000;
> +static int cfq_slice_async = HZ / 1000;
> static int cfq_slice_async_rq = 16;
> -static int cfq_slice_idle = HZ / 249;
> +static int cfq_slice_idle = HZ / 1000;
You need to be careful, on archs with HZ == 100 you just set every time
slice to 0.
> +/* the slice scaling factors */
> +static int cfq_prio_scale[] = {223, 194, 169, 147, 128, /* 0..4 */
> + 111, 97, 84, 73, 64, /* 5..9 */
> + 56, 49, 42, 36, 32, /* 10..14 */
> + 28, 24, 21, 18, 16, /* 15..19 */
> + 14, 12, 11, 9, 8, /* 20..24 */
> + 7, 6, 5, 5, 4, /* 25..29 */
> + 3, 3, 2, 2, 2, /* 30..34 */
> + 1, 1, 1, 1, 1}; /* 35..39 */
I think it's pointless to scale it so fine grained (see my earlier
postings).
Additionally, you don't do anything with the priorities internally.
--
Jens Axboe
next prev parent reply other threads:[~2004-12-13 14:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-13 14:22 IO Priorities Jeff Sipek
2004-12-13 14:38 ` Jens Axboe [this message]
2004-12-13 16:43 ` Jeff Sipek
2004-12-13 16:46 ` Jens Axboe
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=20041213143809.GO3033@suse.de \
--to=axboe@suse.de \
--cc=jeffpc@optonline.net \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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