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]
Message-Id: <201111281542.22258.ms@teamix.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ