From: Jens Axboe <axboe@kernel.dk>
To: Martin Steigerwald <ms@teamix.de>
Cc: linux-kernel@vger.kernel.org, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: CFQ I/O priorities only for reads?
Date: Mon, 28 Nov 2011 15:45:57 +0100 [thread overview]
Message-ID: <4ED39EA5.4000706@kernel.dk> (raw)
In-Reply-To: <201111281542.22258.ms@teamix.de>
On 2011-11-28 15:42, Martin Steigerwald wrote:
> Hi jens und Vivek,
>
> Vivek, I cc'd you, cause you wrote the new cfq-iosched.txt.
>
>
> In trying to understand how I/O priorities actually really work, I tried to dd
> with
>
> rm nullen-id ; sync ; /usr/bin/time ionice -c3 dd if=/dev/zero of=nullen-id
> count=500 bs=1M conv=fsync
>
> versus
>
> rm nullen-rl; sync ; /usr/bin/time ionice -c1 -n0 dd if=/dev/zero of=nullen-rl
> count=500 bs=1M conv=fsync
>
> concurrently. No differences. At first I was puzzled, then I thought maybe
> direct I/O makes a difference. So I tried with oflag=direct.
>
> And it does.
>
> Then I actually read the documentation block/ioprio.txt (3.1 here):
>
>> With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
>> priorities are supported for reads on files. This enables users to io nice
>> processes or process groups, similar to what has been possible with cpu
>> scheduling for ages. This document mainly details the current
>> possibilities with cfq; other io schedulers do not support io priorities
>> thus far.
>
> According to it I/O priorities will even only work on reads. Is that correct?
> I mean they do work on reads, I tested it, but *only* on reads?
>
> From what I see here, it also works for direct I/O write requests
>
> So from what I conclude is that CFQ I/O priorities work for all requests that
> are issued via synchronous system calls, but not for those issued via
> asynchronous calls, i. e. everything that goes through the pagecache.
>
> Is that correct?
Priorities work for reads AND direct writes. In other words, it does not
work for buffered writes.
> Vivek, one thing on cfq-iosched.txt: Could slice_idle=0 make sense on
> SSDs? Later on you write that there are some SSD optimizations in
> place that cut down idling already.
It will have a functional difference even on SSDs, depending on your
workload, even if the scope of idling is smaller on an SSD.
--
Jens Axboe
next prev parent reply other threads:[~2011-11-28 14:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 14:42 Martin Steigerwald
2011-11-28 14:45 ` Jens Axboe [this message]
2011-11-28 15:19 ` [PATCH 1/1] Mention that I/O priorities also work on direct writes Martin Steigerwald
2011-11-30 15:01 ` Martin Steigerwald
2011-11-28 15:22 ` [PATCH 2/3] Replace io by I/O where approbiate Martin Steigerwald
2011-11-28 15:24 ` [PATCH 3/3] Mention that the util-linux package provides an ionice command Martin Steigerwald
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=4ED39EA5.4000706@kernel.dk \
--to=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=ms@teamix.de \
--cc=vgoyal@redhat.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
Powered by JetHome