linux-kernel - Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ

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:   Wed, 31 Aug 2016 23:09:49 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Christoph Hellwig <hch@...radead.org>, Tejun Heo <tj@...nel.org>,
        Jens Axboe <axboe@...nel.dk>
Cc:     Paolo Valente <paolo.valente@...aro.org>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        ulf.hansson@...aro.org, linus.walleij@...aro.org,
        Omar Sandoval <osandov@...com>
Subject: Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ

On Mon, Aug 08, 2016 at 06:19:54AM -0700, Christoph Hellwig wrote:

> please don't spend more time on the legacy request interface.  If you
> want your work included and make an impact add it to blk-mq.

So, an update on this: off-list Tejun said that he'd spoken with Jens
and agreed that nothing should be changed in the block layer and
everything should be focused on blk-mq at this point.  This is obviously
very disappointing especially given the previous reviews - Christoph had
been very clear but it wasn't clear to us that everyone agreed with him.

I do agree (as I think everyone looking at BFQ does) that we do want to
work to replace the current block code with blk-mq but it really feels
that we're still quite a way from being able to deploy it on systems
with MMC or SD storage where we're particularly looking with this work.
The big thing that needs doing is the queuing and scheduling which these
devices don't make any effort to do in hardware.  Omar has been working
on this but the work has mostly been off-list thus far AFAICT so not
terribly visible.  Once that's there the individual subsystems will need
to be converted, that's fairly mechanical code wise but is obviously
going to need some studying of the performance in order to make sure we
don't cause problems for users.  This all seems like at least a couple
of releases worth of work rather than being at the point where the
current code can be deprecated.

So, how do we take this forward?  In terms of Linaro's work what we've
been thinking is:

 - Send a proposal for a face to face discussion at Kernel Summit (Paolo
   will be going there), Paolo said he was drafting a mail.
 - Continue maintaining and testing BFQ, most likely reverting to a
   separate scheduler rather than replacing CFQ.
 - Do some benchmarks on the current status of the various branches on
   relevant hardware (including trying to convert some of these slower
   devices to blk-mq and seeing what happens).  Linus has been working
   on this already in the context of MMC.
 - Try to pitch in to the blk-mq development, we'll need to work out how
   to coordinate with everyone else here.

I personally feel that given that it looks like this is all going to
take a while it'd still be good to merge BFQ at least as an alternative
scheduler so that people can take advantage of it while the work on
modernising everything to use blk-mq - that way we can hopefully improve
the state of the art for users in the short term or at least help get
some wider feedback on how well this works in the real world
independently of the work on blk-mq.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)