Hello, Tao. On Fri, 18 Sep 2026 13:49:56 +0800, Tao Cui wrote:
> The registration and binding model follows the TCP congestion > control model registration pattern: registering a struct_ops makes > the model available by its name, while io.cost.model binds one > registered model to a device with "model=<name>" and restores the > builtin model with "model=linear". Alexei is right, this isn't what I meant. One struct_ops instance per device: attaching binds the instance to the device and switches the device to the model, detaching switches it back to the builtin. That removes the name registry, the lifecycle list and the refcounting on top of the struct_ops map reference. Putting the device id in the struct_ops the way hid_bpf_ops does works fine. I don't have a strong opinion on how the device is identified. > u64 calc_cost(u64 opf, u64 nbytes, sector_t sector, > struct blkcg *blkcg, u64 model_flags) Why not pass the bio itself? The model can read whatever it needs from it. The merge indicator still needs the flags argument as it isn't a property of the bio. > blkcg is passed so the model can key > per-cgroup state; state stored in BPF_MAP_TYPE_CGRP_STORAGE > follows the cgroup lifetime, and optional blkcg_online()/ > blkcg_offline() callbacks mirror the css lifecycle for models > which want eager setup or teardown. With a per-device instance, these should be bound to the iocg pd init and free rather than the blkcg css. That gives the model the same per cgroup per device lifetime as the builtin cursor and drops the global mutex from the cgroup online and offline paths. > The completion-time request sizing for the > latency met/missed accounting still uses the builtin coefficients > (the request's bio, and with it the issuing cgroup, is gone by then); > extending the model there is left open by this interface. Let's be explicit here. For now, the struct_ops should carry the transfer cost coefficients, vtime per page for reads and writes, and the builtin latency tracking and vrate adjustment should use these instead of the linear coefficients while the model is attached. Down the line, a model should be able to take over the QoS side too. The vrate adjustment is driven by an empirically derived table and being able to replace it is a good part of the value of a pluggable model. The shape I have in mind is an rq_done(struct request *) callback which disables the builtin latency tracking and periodic vrate adjustment, with the model modulating directly through kfuncs to set the base vrate and the saturation state and to read the block layer clock. That doesn't have to be part of this series. While a model is attached, the linear coefficients are inert. Coefficient writes can be stored and take effect again on detach, autop shouldn't step profiles based on vrate the same way it doesn't when the cost model is user-set, and io.cost.model can report the model in the model field, in a form which identifies it as a BPF model, with ctrl still describing the coefficients. Thanks. -- tejun
