| Message ID | 20240618031751.3470464-1-yukuai1@huaweicloud.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | blk-iocost: support to build iocost as kernel module | expand |
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 > > > . >
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(-)