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. > 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. > 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. Thanks. -- tejun
