linux-kernel - Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

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:	Fri, 11 Mar 2016 08:38:39 -0500
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Tejun Heo <tj@...nel.org>,
	Paolo Valente <paolo.valente@...aro.org>,
	Jens Axboe <axboe@...nel.dk>,
	Fabio Checconi <fchecconi@...il.com>,
	Arianna Avanzini <avanzini.arianna@...il.com>,
	linux-block@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O
 scheduler

On 2016-03-11 06:16, Christoph Hellwig wrote:
> On Fri, Mar 04, 2016 at 01:10:31PM -0500, Austin S. Hemmelgarn wrote:
>> 1. This all started long before blk-mq hit mainline.
>
> Whoe cares? :)
It wasn't intended as an argument for this continuing to be developed 
outside of blk-mq, but as an explanation of why the code exists as it 
does right now.
>> 2. There's still a decent amount of block drivers that don't support blk-mq.
>> Last time I looked (around the time 4.4 came out), I saw the following that
>> either obviously don't support it, or are ambiguous as to whether they
>> support it or not.  Here's a list of just the ones I know are being used on
>> existing systems running relatively recent kernel versions, not including
>
> There is no ambiguouity.  You clearly named a few ones that aren't
> converted, but also a lot of make_request_fn based drivers which don't
> support any I/O scheduler.
For someone reading the code there might not be any ambiguity, but from 
the perspective of someone who isn't reading the code (or even someone 
who has limited background in kernel programming), it very much is 
ambiguous, especially what does and doesn't support I/O scheduling in 
general.
> But that whole point is that anything actively developed should move
> over.
Agreed.