linux-kernel - CFQ I/O priorities only for reads?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Nov 2011 15:42:21 +0100
From:	Martin Steigerwald <ms@...mix.de>
To:	Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org
Cc:	Vivek Goyal <vgoyal@...hat.com>
Subject: CFQ I/O priorities only for reads?

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?

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.

Thanks,
-- 
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/