linux-kernel - Re: [WIP BRANCH] cgroups support in bfq-mq WIP branch

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: <97eadcb9-5049-399a-e5a7-d4f8b821756b@kernel.dk>
Date:   Sat, 25 Feb 2017 11:52:40 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Paolo Valente <paolo.valente@...aro.org>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        "tj@...nel.org" <tj@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        Bart Van Assche <bart.vanassche@...disk.com>
Subject: Re: [WIP BRANCH] cgroups support in bfq-mq WIP branch

On 02/25/2017 10:44 AM, Paolo Valente wrote:
> Hi,
> I've just completed cgroups support, and I'd like to highlight the
> main blk-mq issue that I have found along the way.  I have pushed the
> commit that completes the support for cgroups to the usual WIP branch
> [1].  Before moving to this issue, I have preliminary question about
> the scheduler name, since I'm about to start preparing the patch
> series for submission.  So far, I have used bfq-mq as a temporary
> name.  Are we fine with it, or should I change it, for example, to
> just bfq?  Jens?

Just call it 'bfq', that doesn't conflict with anything that's
in the kernel already.

> I've found a sort of circular dependency in blk-mq, related to
> scheduler initialization.  To describe both the issue and how I've
> addressed it, I'm pasting the message of the new commit.

Rebase your patches on top of Linus current master, some of them
will need to change and some can be dropped.

And disentangle it completely from the old bfq, I don't want to see
nasty stuff like includes of .c files with prior defines modifying
behavior of functions.

When that's done, get it posted for review asap. I would imagine
we will go through a few postings and review cycles, and if we're
targeting 4.12 with this, then we should get the ball rolling
on that side.

-- 
Jens Axboe