Re: [tip: sched/core] sched/topology: Compute sd_weight considering cpuset partitions

[Chen, Yu C]

On 3/21/2026 6:13 PM, K Prateek Nayak wrote:
> On 3/21/2026 3:15 PM, K Prateek Nayak wrote:
> > So this is what I've found: By default we have:
> >
> >    cpumask_size: 4
> >    struct sched_domain size: 296
> >
> > If I do:
> >
> > diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
> > index a1e1032426dc..f0bebce274f7 100644
> > --- a/include/linux/sched/topology.h
> > +++ b/include/linux/sched/topology.h
> > @@ -148,7 +148,7 @@ struct sched_domain {
> >   	 * by attaching extra space to the end of the structure,
> >   	 * depending on how many CPUs the kernel has booted up with)
> >   	 */
> > -	unsigned long span[];
> > +	unsigned long span[1];
> >   };
> >   
> >   static inline struct cpumask *sched_domain_span(struct sched_domain *sd)
> > ---
> >
> > I still see:
> >
> >    cpumask_size: 4
> >    struct sched_domain size: 296
> >
> > Which means we are overwriting the sd->span during *sd assignment even
> > with the variable length array at the end :-(

Ah, that's right.

> And more evidence - by default we have:
>
>    sched_domain size: 296
>    offset of sd_span: 292
>
> sizeof() seems to account some sort of 4-byte padding for the struct which
> pushes the offset of sd->span into the struct size.

In your disassembly for *sd = {...}

mov     r2, #296
mov     r0, fp
mov     r1, #0
...
bl memset  <-- oops!

> To resolve this, we can also do:
>
> diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
> index a1e1032426dc..48bea2f7f750 100644
> --- a/include/linux/sched/topology.h
> +++ b/include/linux/sched/topology.h
> @@ -148,7 +148,7 @@ struct sched_domain {
>   	 * by attaching extra space to the end of the structure,
>   	 * depending on how many CPUs the kernel has booted up with)
>   	 */
> -	unsigned long span[];
> +	unsigned long span[] __aligned(2 * sizeof(int));
>   };
>   
>   static inline struct cpumask *sched_domain_span(struct sched_domain *sd)
> ---
>
> and the kernel boots fine with the sd_span offset aligned with
> sched_domain struct size:
>
>    sched_domain size: 296
>    offset of sd_span: 296
>
>
> So Peter, which solution do you prefer?
>
> 1. Doing cpumask_and() after the *sd = { ... } initialization. (or)
>
> 2. Align sd->span to an 8-byte boundary.

I vote for option 1, as option 2 relies on how the compiler
interprets sizeof() and the offset of each member within
the structure IMO. Initializing the values after *sd = {} seems
safer and more generic, but the decision is up to Peter : )

thanks,
Chenyu