linux-kernel - Re: [PATCH V4 00/15] blk-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: <20161115000529.GA15160@shli-mbp.local>
Date:   Mon, 14 Nov 2016 16:05:30 -0800
From:   Shaohua Li <shli@...com>
To:     Bart Van Assche <bart.vanassche@...disk.com>
CC:     <linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <Kernel-team@...com>, <axboe@...com>, <tj@...nel.org>,
        <vgoyal@...hat.com>
Subject: Re: [PATCH V4 00/15] blk-throttle: add .high limit

On Mon, Nov 14, 2016 at 02:46:22PM -0800, Bart Van Assche wrote:
> On 11/14/2016 02:22 PM, Shaohua Li wrote:
> > The background is we don't have an ioscheduler for blk-mq yet, so we can't
> > prioritize processes/cgroups. This patch set tries to add basic arbitration
> > between cgroups with blk-throttle. It adds a new limit io.high for
> > blk-throttle. It's only for cgroup2.
> 
> Hello Shaohua,
> 
> My understanding of this work is that a significant part of it will have to
> be reverted once blk-mq supports I/O scheduling, e.g. the code for detecting
> whether the I/O submitter is idle. Shouldn't this kind of infrastructure be
> added after support has been added in blk-mq for I/O scheduling?

Sure, if we have a CFQ-like io scheduler for blk-mq, this is largly not
required. But we don't have one yet and nothing is floating around either. The
conservative throttling is relatively easy to implement and achive similar
goal. The throttling could be still useful even with ioscheduler as throttling
is faster if we are talking about CFQ-like scheduler. I don't think this should
be blocked to wait for I/O scheduling. There was a long discussion in last
post, and we agreed the throttling and io scheduler aren't mutually exclusive.
http://marc.info/?l=linux-kernel&m=147552964708965&w=2

Thanks,
Shaohua