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: <7489a7f8-2589-29de-1c95-b99d1d9b1850@gmail.com>
Date:   Thu, 24 Feb 2022 10:50:22 +0800
From:   Wang Jianchao <jianchao.wan9@...il.com>
To:     Tejun Heo <tj@...nel.org>
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 2022/2/24 10:07 上午, Tejun Heo wrote:
> Hello,
> 
> On Thu, Feb 24, 2022 at 09:51:04AM +0800, Wang Jianchao wrote:
>> The initial version of this patchset has two targets:
>> (1) Add a sysfs interface to open/close the policy per device. Then we needn't
>>     waste cpu cycles and memory if the device doesn't need the policy.
>> (2) Make the policies modular, then it easy to maintain the code of policy in
>>     production environment as we only need to close the policy and replace the
>>     .ko file.
>>
>> The loading module when open policy in sysfs interface is just to avoid modprobe
>> manually. There is similar operation when switch io scheduler.
> 
> Each rq-qos mechanism already needs and has a way to turn off itself.
> There's no reason to add another layer on top. If the current way of
> disabling isn't efficient, we should improve that instead of adding a new
> layer of interface on top.

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.

Thanks
Jianchao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ