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

["Chen, Yu C" <yu.c.chen@intel.com>]

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