From: Yu Kuai <yukuai3@huawei.com>

Changes from RFC v1:
 - replace the first patch.
 - add commit message of our motivation and advantages to build iocost
 as kernel module.

The motivation is that iocost is not used widely in our production, and
some customers don't want to increase kernel size to enable iocost that
they will never use, and it'll be painful to maintain a new downstream
kernel. Hence it'll be beneficially to build iocost as kernel module:

- Kernel Size and Resource Usage, modules are loaded only when their
specific functionality is required.

- Flexibility and Maintainability, allows for dynamic loading and unloading
of modules at runtime without the need to recompile and restart the kernel,
for example we can just replace blk-iocost.ko to fix iocost CVE in our
production environment.

Yu Kuai (7):
  blk-cgroup: add a new helper pr_cont_blkg_path()
  cgroup: export cgroup_parse_float
  block: export some API
  blk-iocost: factor out helpers to handle params from ioc_qos_write()
  blk-iocost: parse params before initializing iocost
  blk-iocost: support to free iocost
  blk-iocost: support to build iocost as kernel module

 block/Kconfig             |   2 +-
 block/blk-cgroup.c        |  10 ++
 block/blk-cgroup.h        |   1 +
 block/blk-iocost.c        | 225 ++++++++++++++++++++++++++------------
 block/blk-rq-qos.c        |   2 +
 include/linux/blk_types.h |   2 +-
 kernel/cgroup/cgroup.c    |   1 +
 7 files changed, 170 insertions(+), 73 deletions(-)

-- 
2.39.2

On Tue, Jun 18, 2024 at 11:17:44AM +0800, Yu Kuai wrote:
> The motivation is that iocost is not used widely in our production, and
> some customers don't want to increase kernel size to enable iocost that
> they will never use, and it'll be painful to maintain a new downstream
> kernel. Hence it'll be beneficially to build iocost as kernel module:
> 
> - Kernel Size and Resource Usage, modules are loaded only when their
> specific functionality is required.
> 
> - Flexibility and Maintainability, allows for dynamic loading and unloading
> of modules at runtime without the need to recompile and restart the kernel,
> for example we can just replace blk-iocost.ko to fix iocost CVE in our
> production environment.

Given the amount of new exports and infrastructure it adds this still
feels like a bad tradeoff.

Hi,

在 2024/06/18 15:12, Christoph Hellwig 写道:
> On Tue, Jun 18, 2024 at 11:17:44AM +0800, Yu Kuai wrote:
>> The motivation is that iocost is not used widely in our production, and
>> some customers don't want to increase kernel size to enable iocost that
>> they will never use, and it'll be painful to maintain a new downstream
>> kernel. Hence it'll be beneficially to build iocost as kernel module:
>>
>> - Kernel Size and Resource Usage, modules are loaded only when their
>> specific functionality is required.
>>
>> - Flexibility and Maintainability, allows for dynamic loading and unloading
>> of modules at runtime without the need to recompile and restart the kernel,
>> for example we can just replace blk-iocost.ko to fix iocost CVE in our
>> production environment.
> 
> Given the amount of new exports and infrastructure it adds this still
> feels like a bad tradeoff.

Yes, I understand your concern, let's see if we can export less and
hopefully accept the tradeoff. :) All other cgroup policies and wbt can
benefit the same without more helpers to be exported.

Thanks,
Kuai
> 
> 
> .
>