linux-kernel - Re: [RFC V4 1/6] blk: prepare to make blk-rq-qos pluggable and modular

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yhe38VnBq7VzUBAV@slm.duckdns.org>
Date:   Thu, 24 Feb 2022 06:53:05 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Wang Jianchao <jianchao.wan9@...il.com>
Cc:     Jens Axboe <axboe@...nel.dk>, Josef Bacik <jbacik@...com>,
        Bart Van Assche <bvanassche@....org>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC V4 1/6] blk: prepare to make blk-rq-qos pluggable and
 modular

On Thu, Feb 24, 2022 at 10:50:22AM +0800, Wang Jianchao wrote:
> Yes, right now, every policy has their own way to turn off, but we always need to
> iterate the rqos list and enter into the policy's callback to check it. And every
> blkio cgroup needs to allocate memory for it even we don't use it.
> 
> I don't this patchset is adding a new layer, but blk-rq-qos layer has been already
> there , we just add a unified interface to open/close the policies.

We're talking in circles. We already know when a policy is inactive. If it
sits in hot path in that state, take it off whatever gets iterated in hot
path and put it back on when it actually gets enabled. The same goes for
memory allocation. If there's substantial amount of memory allocted while
not used, make that dynamic and trigger it when the policy starts getting
used. It makes no sense to add another enable/disable interface on top.

FWIW, please consider the series nacked on this side.

Thanks.

-- 
tejun