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 CFQ I/O priorities only for reads? 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 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.