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(-)

-- 
2.39.2

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