Re: [PATCH] sched_ext: Skip per-CPU data allocation for built-in DSQs

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng@xxxxxxxxxx>

On Thu, 27 Aug 2026 16:23:29 +0800, Qiurong Fang wrote:
> Every built-in DSQ still carries nr_cpu_ids * sizeof(struct
> scx_dsq_pcpu) bytes of dead per-CPU memory.

It is quadratic rather than linear, which is worth saying.  The number of
built-in DSQs scales with nr_cpu_ids too, because most of them are
initialised inside for_each_possible_cpu():

  ext.c:8681  SCX_DSQ_LOCAL
  ext.c:8683  SCX_DSQ_REJECT   (CONFIG_EXT_SUB_SCHED)
  ext.c:7172  SCX_DSQ_BYPASS
  sub.c:672   SCX_DSQ_RESCUE   (per rq, via scx_rescue_init())

Only SCX_DSQ_GLOBAL is a single instance.  Each of those then allocates
nr_cpu_ids entries, so what you drop is on the order of nr_cpu_ids^2
struct scx_dsq_pcpu, which on a large machine is a very different number
from the one the changelog suggests.

The guard holds.  ext.c:1130 is the only read of dsq->pcpu, and it already
sits under !(dsq->id & SCX_DSQ_FLAG_BUILTIN) at 1127, the complement of
what you skip on; the local DSQ branch above uses sch->pcpu instead.  All
five ids passed to scx_init_dsq() carry the flag (sched/ext.h:58-62), so
nothing is missed either.  exit_dsq() contains nothing but the pcpu walk
and the free, so the early return skips nothing else, and it is needed
rather than tidy: per_cpu_ptr(NULL, cpu) hands the loop an offset pointer
and list_empty() would read it, so relying on free_percpu(NULL) alone
would not do.

Two smaller things.  A Fixes: tag routes this to stable, which is more
than a memory saving asks for unless you see a correctness angle.  And the
mail header says "Qiurong Fang" while the From: and Signed-off-by in the
body say "fangqiurong".

Thanks,
Zhan Xusheng