Re: [RFC PATCH v7 0/4] blk-iocost: BPF struct_ops cost model

[Tao Cui <cui.tao@linux.dev>]

Hello, Tejun.

在 2026/9/29 08:42, Tejun Heo 写道:
> Hello, Tao.
> 
> On Thu, 24 Sep 2026 13:45:45 +0800, Tao Cui wrote:
> 
>> loading attaches the model to
>> that device and switches it away from the builtin linear model,
>> detaching the struct_ops restores the builtin model, and the
>> struct_ops core owns the program lifetime.
> 
> I don't think attaching should enable the controller. v7 currently turns
> it on without the queue freeze and quiesce that ioc_qos_write() goes
> through. Attaching can create the ioc if needed like an io.cost.model
> write does and switch the model under the same freeze and quiesce,
> leaving enabling to io.cost.qos.
> 
> This is different from what I said on v1, where switching back to the
> builtin model detached the struct_ops, but with the controller state left
> to io.cost.qos it seems more consistent to keep the attachment independent
> too. Writing enable=0 or model=linear wouldn't detach the struct_ops,
> model=bpf would switch back to the attached model, and only detaching
> would remove it. This is the same as the linear coefficients, which are
> kept while the BPF model is in use and take effect again when switched
> back.
> 

Done.  The implicit enable and the wbt_disable_default() are gone.
Attaching now checks disk_live() and creates the ioc under
rq_qos_mutex, like blkg_conf_open_bdev() does, and switches the
active model under the same freeze and quiesce sequence as the
io.cost.model writes.

To make sure I understood correctly: attaching switches the active
model to the attached BPF model, while model=linear and model=bpf
only switch between the attached model and the builtin model without
affecting the attachment itself.  The attachment survives enable=0,
and only .unreg removes it.  Please shout if I still got that wrong.

>> iocg_init()/iocg_free()
>> callbacks, invoked from the iocg policy init and free paths with
>> the same per (cgroup, device) lifetime, let models manage their own
>> per-cgroup state.
> 
> Existing cgroups don't get iocg_init() on attach and iocg_free() isn't
> delivered on detach, so init and free don't pair up. Can you call
> iocg_init() for all existing iocgs on attach and iocg_free() for the
> remaining ones on detach? That's what sched_ext does with
> ops.cgroup_init() and ops.cgroup_exit() on enable and disable.
> 

Done.  One note on the implementation: the existing iocgs are walked
over q->blkg_list under q->blkcg_mutex, the same walk the blkcg
policy teardown uses, rather than over the cgroup tree - this is a
per-device walk and the queue is frozen and quiesced at that point.
Cgroups without a blkg on the device yet are not missed: their blkg
is created later and ioc_pd_init()/ioc_pd_free() deliver the
callbacks then, so init and free pair up either way.
>> Writing "ctrl=bpf" or "model=bpf" is accepted as a no-op so a saved
>> configuration still parses; re-attaching the model requires loading
>> the struct_ops again, not writing to this file.
> 
> ctrl keeps describing the coefficients and never reads back "bpf", so
> ctrl=bpf shouldn't be accepted. model=bpf should fail when no model is
> attached.
> 
Done as suggested; the bpf-ci review of v7 reported the same two.

Thanks.
Tao> Thanks.
> 
> --
> tejun