Re: [RFC v3 0/3] block: Introduce a BPF-based I/O scheduler

[Alexei Starovoitov]

On Sat, Oct 03, 2026 at 12:27 PM Kaitao Cheng <kaitao.cheng@xxxxxxxxx> wrote:
> PFQ gives us a concrete policy to explore how well the UFQ interface
> supports more involved scheduling decisions and to guide further work on
> the framework. It has not yet been used in production, and further testing
> and workload evaluation are needed.

Third version in six months and still not a single number.
v2 got replies from the bots only.
Without a solid use case there is no point in polishing this.

> In particular, I would appreciate suggestions on the boundary between the
> UFQ framework and BPF policies, the struct_ops interface, and request
> ownership and fallback handling.

One global ufq_ops for all disks is not the best shape.
I'd do it like bpf_qdisc.

The ownership is the bigger problem.
The request sits in ctx->rq_lists and in a bpf map at the same time
and the kernel relies on the prog to keep the two in sync.
The prog holds rq->ref. rq holds q_usage_counter until
__blk_mq_free_request(). One request that the prog didn't return
from dispatch_req or left in a map and blk_mq_freeze_queue() waits
forever.
sched_ext has a watchdog that kicks the bpf scheduler out.
Something like that is necessary here too.

pw-bot: cr