Re: [PATCH sched_ext/for-7.3 31/32] tools/sched_ext: scx_qmap - Expand hierarchical sub-scheduling

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing atomic increment for sub-scheduler dispatch counter (`nr_dsps`).
--

commit ce8113fd0fe8bd38281cc676e6e4f5bc5e262e96
Author: Tejun Heo <tj@kernel.org>

tools/sched_ext: scx_qmap - Expand hierarchical sub-scheduling

This commit expands scx_qmap to demonstrate cap-based cid delegation for
hierarchical sub-scheduling. It allows a parent to delegate exclusive cids
to child cgroup sub-schedulers based on cpu.weight. Remaining cids form a
shared pool that is round-robined among participants.

> diff --git a/tools/sched_ext/scx_qmap.bpf.c b/tools/sched_ext/scx_qmap.bpf.c
> index f6cfe63425d36..938a32514b2f6 100644
> --- a/tools/sched_ext/scx_qmap.bpf.c
> +++ b/tools/sched_ext/scx_qmap.bpf.c
[ ... ]
> @@ -567,11 +627,34 @@ void BPF_STRUCT_OPS(qmap_dispatch, s32 cid, struct task_struct *prev)
[ ... ]
> +	} else if (owner >= 0 && owner < MAX_SUB_SCHEDS &&
> +		   qa.sub_sched_ctxs[owner].cgroup_id) {
> +		if (scx_bpf_sub_dispatch(qa.sub_sched_ctxs[owner].cgroup_id))
> +			qa.sub_sched_ctxs[owner].nr_dsps++;

[Severity: Medium]
Since qmap_dispatch() can run concurrently on multiple CPUs delegated to the
same sub-scheduler owner, will this non-atomic increment lead to lost
updates?

When multiple CPUs update this counter simultaneously, it looks like data
races can cause lost increments, resulting in incorrect statistics and an
under-reporting of disp/s in the userspace tool. Would it be better to use
an atomic add here, similar to how other counters are handled?

> +		return;
> +	}
>  
>  	if (!qa.nr_highpri_queued && scx_bpf_dsq_move_to_local(SHARED_DSQ, 0))
>  		return;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703080159.2314350-1-tj@kernel.org?part=31