linux-kernel - Re: [PATCH V3 00/11] block-throttle: add .high limit

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: <20161006110342.gyyiwaqw4ivzdaww@sirena.org.uk>
Date:   Thu, 6 Oct 2016 13:03:42 +0200
From:   Mark Brown <broonie@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Tejun Heo <tj@...nel.org>,
        Paolo Valente <paolo.valente@...more.it>,
        Shaohua Li <shli@...com>, Vivek Goyal <vgoyal@...hat.com>,
        linux-block@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jens Axboe <axboe@...com>, Kernel-team@...com,
        jmoyer@...hat.com, Ulf Hansson <ulf.hansson@...aro.org>,
        Hannes Reinecke <hare@...e.com>
Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit

On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote:
> On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo <tj@...nel.org> wrote:

> > I get that bfq can be a good compromise on most desktop workloads and
> > behave reasonably well for some server workloads with the slice
> > expiration mechanism but it really isn't an IO resource partitioning
> > mechanism.

> Not just desktops, also Android phones.

> So why not have BFQ as a separate scheduling policy upstream,
> alongside CFQ, deadline and noop?

Right.

> We're already doing the per-usecase Kconfig thing for preemption.
> But maybe somebody already hates that and want to get rid of it,
> I don't know.

Hannes also suggested going back to making BFQ a separate scheduler
rather than replacing CFQ earlier, pointing out that it mitigates
against the risks of changing CFQ substantially at this point (which
seems to be the biggest issue here).

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