Re: [PATCHSET sched_ext/for-7.2] sched_ext: Topological CPU IDs and cid-form struct_ops

[Cheng-Yang Chou]

Hi Tejun,

On Mon, Apr 20, 2026 at 09:19:29PM -1000, Tejun Heo wrote:
> Hello,
> 
> This patchset introduces topological CPU IDs (cids) - dense,
> topology-ordered cpu identifiers - and an alternative cid-form struct_ops
> type that lets BPF schedulers operate in cid space directly.
> 
> Key pieces:
> 
> - cid space: scx_cid_init() walks nodes * LLCs * cores * threads and packs
>   a dense cid mapping. The mapping can be overridden via
>   scx_bpf_cid_override(). See "Topological CPU IDs" in ext_cid.h for the
>   model.
> 
> - cmask: a base-windowed bitmap over cid space. Kernel and BPF helpers with
>   identical semantics. Used by scx_qmap for per-task affinity and idle-cid
>   tracking; meant to be the substrate for sub-sched cid allocation.
> 
> - bpf_sched_ext_ops_cid: a parallel struct_ops type whose callbacks take
>   cids/cmasks instead of cpus/cpumasks. Kernel translates at the boundary
>   via scx_cpu_arg() / scx_cpu_ret(); the two struct types share offsets up
>   through @priv (verified by BUILD_BUG_ON) so the union view in scx_sched
>   works without function-pointer casts. Sub-sched support is tied to
>   cid-form: validate_ops() rejects cpu-form sub-scheds and cpu-form roots
>   that expose sub_attach / sub_detach.
> 
> - cid-form kfuncs: scx_bpf_kick_cid, scx_bpf_cidperf_{cap,cur,set},
>   scx_bpf_cid_curr, scx_bpf_task_cid, scx_bpf_this_cid,
>   scx_bpf_nr_{cids,online_cids}, scx_bpf_cid_to_cpu, scx_bpf_cpu_to_cid.
>   A cid-form program may not call cpu-only kfuncs (enforced at verifier
>   load via scx_kfunc_context_filter); the reverse is intentionally
>   permissive to ease migration.
> 
> - scx_qmap port: scx_qmap is converted to cid-form. It uses the cmask-based
>   idle picker, per-task cid-space cpus_allowed, and cid-form kfuncs
>   throughout. Sub-sched dispatching via scx_bpf_sub_dispatch() continues to
>   work.

I have gone through the entire patchset, and it lgtm.
For the whole series:

Reviewed-by: Cheng-Yang Chou <yphbchou0911@xxxxxxxxx>

I have two questions regarding the current implementation:

1. Regarding the ext_cid feature (same as ext_idle), is it feasible to
   implement this within the BPF arena instead of the current approach?

2. I noticed rust/kernel/cpumask.rs is already in tree. While I understand
   that arch support for Rust is currently limited, would it be a good time
   to start adding Rust abstractions to maintain parity or reduce code
   duplication? (as I discussed offline w/ Andrea about re-implementing
   ext_idle in Rust, and now w/ ext_cid as well)

-- 
Cheers,
Cheng-Yang