linux-kernel - Re: [PATCH] cfq-iosched: non-rot devices do not need read queue merging

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4e5e476b1001070538y35143cc8me7443f3eb0d377@mail.gmail.com>
Date:	Thu, 7 Jan 2010 14:38:29 +0100
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Kirill Afonshin <kirill_nnov@...l.ru>
Cc:	Jeff Moyer <jmoyer@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Linux-Kernel <linux-kernel@...r.kernel.org>,
	Shaohua Li <shaohua.li@...el.com>,
	Gui Jianfeng <guijianfeng@...fujitsu.com>
Subject: Re: [PATCH] cfq-iosched: non-rot devices do not need read queue 
	merging

Hi Kirill,
NCQ is actually measured, so it is reliable.
Rotational can be wrong, but you can write to it (e.g. at machine
startup) to obtain better handling of your disks.
I am also a fan of auto-tuning, and trying to achieve it in cfq, but
it is kind of complex, since there are many factors, and some of them
aren't modeled by cfq currently.
An example is that, on cheap SSDs or flash cards, small writes are far
slower than anything else (they can take up to 0.5s), while a read
will usually take less than 1ms. Currently, CFQ has no way to handle
this extreme situation, since it uses just one idle value (8ms) for
all transitions.

Corrado

On 1/7/10, Kirill Afonshin <kirill_nnov@...l.ru> wrote:
> I think we should not rely on NCQ/non-NCQ or blk_queue_nonrot() because it
> may be incorrect:
> try this:
>
> find /sys/ -name rotational 2>/dev/null
> find /sys/ -name rotational 2>/dev/null|xargs cat
>
> all devices are reported as rotational for me including ram, loop and usb
> flash drive. Physical block size and optimal io size has invalid values for
> all my usb flash drives.
>
> I think it would be better to do a short performance test before mount. It
> will provide all necessary information for io scheduler. We doesn't need
> information about NCQ and rotational. We need to predict how much time
> specific io operation will take in current context.
>
> PS: I'm not native speaker.
>
> Best regards,
> Kirill Afonshin
>
--
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/