| Message ID | 20240406080059.2248314-1-yukuai1@huaweicloud.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | blk-throttle: support enable and disable during runtime | expand |
On Sat, Apr 06, 2024 at 04:00:53PM +0800, Yu Kuai <yukuai1@huaweicloud.com> wrote:
> I'm planning to support build all blk-throttle polices as kernel module,
There is only one blk-throttle policy (especially after your removal of
io.low). Did you mean blkcg policies in general?
The current code is complex because of various lifecycles in
devices x cgroups.
Turning policies into modules seems to make it
devices x cgroups x policy modules
.
Could you please add more info why policies as modules is beneficial,
how to keep complexity capped?
Thanks,
Michal
Hi, 在 2024/04/16 23:56, Michal Koutný 写道: > On Sat, Apr 06, 2024 at 04:00:53PM +0800, Yu Kuai <yukuai1@huaweicloud.com> wrote: >> I'm planning to support build all blk-throttle polices as kernel module, > > There is only one blk-throttle policy (especially after your removal of > io.low). Did you mean blkcg policies in general? Yes, bfq already support that, and others are all rq_qos based, they will be much easier than blk-throtl. > > The current code is complex because of various lifecycles in > devices x cgroups. > Turning policies into modules seems to make it > devices x cgroups x policy modules > . > > Could you please add more info why policies as modules is beneficial, > how to keep complexity capped? First of all, users can only load these policies when they need, and reduce kernel size; Then, when these policies is not loaded, IO fast path will be slightly shorter, and save some memory overhead for each disk. Thanks, Kuai > > Thanks, > Michal >
On Wed, Apr 17, 2024 at 09:09:07AM +0800, Yu Kuai <yukuai1@huaweicloud.com> wrote: > Yes, bfq already support that, I've never noticed CONFIG_IOSCHED_BFQ is a tristate that explains (me) a lot. Thanks! > First of all, users can only load these policies when they need, and > reduce kernel size; Then, when these policies is not loaded, IO fast > path will be slightly shorter, and save some memory overhead for each > disk. ...and there is no new complexity thanks to the above. (I'm only catching up with subthread of patch 5/6.) It seems the old complexity could be simplified by the way of lazy inits. Intereseting... Michal
From: Yu Kuai <yukuai3@huawei.com> Hi, all! I'm planning to support build all blk-throttle polices as kernel module, this is the first part for blk-throttle: - patch 1 remove THROTTLE LOW; - patch 2 delay initialization from disk initialization to configuration; - patch 3-5 support to destroy blk-throttle is it's disabled; - patch 6 switch blk-throttle to use rq_qos to stop exposing blk-throttle internal implementations; Changes from RFV v1: - add missing places in patch 1; - add patch 2-6; Yu Kuai (6): blk-throttle: remove CONFIG_BLK_DEV_THROTTLING_LOW blk-throttle: delay initialization until configuration blk-throttle: expand tg_conf_updated() to return if any tg has rules blk-cgroup: add a new helper blkg_conf_exit_blkg() blk-throttle: support to destroy throtl_data when blk-throttle is disabled blk-throtl: switch to use rq_qos Documentation/ABI/stable/sysfs-block | 12 - arch/loongarch/configs/loongson3_defconfig | 1 - block/Kconfig | 11 - block/bio.c | 1 - block/blk-cgroup.c | 25 +- block/blk-cgroup.h | 1 + block/blk-core.c | 4 +- block/blk-merge.c | 2 +- block/blk-mq-debugfs.c | 2 + block/blk-rq-qos.c | 13 + block/blk-rq-qos.h | 11 + block/blk-stat.c | 3 - block/blk-sysfs.c | 9 - block/blk-throttle.c | 1598 ++++++-------------- block/blk-throttle.h | 76 +- block/blk.h | 11 - block/genhd.c | 3 - include/linux/blkdev.h | 4 - 18 files changed, 495 insertions(+), 1292 deletions(-)