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]

Date:	Thu, 7 Jan 2010 09:36:40 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Corrado Zoccolo <czoccolo@...il.com>
Cc:	Kirill Afonshin <kirill_nnov@...l.ru>,
	Jeff Moyer <jmoyer@...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

On Thu, Jan 07, 2010 at 02:38:29PM +0100, Corrado Zoccolo wrote:
> 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.

Hi Corrado, 

How does idle time value relate to flash card being slower for writes? If
flash card is slow and we choose to idle on queue (because of direct
writes), idle time value does not even kick in. We just continue to remain
on same cfqq and don't do dispatch from next cfqq.

Idle time value will matter only if there was delay from cpu side or from
workload side in issuing next request after completion of previous one.

Thanks
Vivek

> 
> 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/