Re: [PATCH v3 3/8] sched/topology: Switch to assigning "sd->shared" from s_data

[Shrikanth Hegde <sshegde@linux.ibm.com>]

On 1/22/26 2:06 PM, K Prateek Nayak wrote:
> Hello Shrikanth,
> 
> On 1/22/2026 1:42 PM, Shrikanth Hegde wrote:
>>> @@ -2709,6 +2720,9 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
>>>            if (!cpumask_test_cpu(i, cpu_map))
>>>                continue;
>>>    +        if (atomic_read(&(*per_cpu_ptr(d.sds, i))->ref))
>>> +            *per_cpu_ptr(d.sds, i) = NULL;
>>> +
>>
>> Can we do this claim_allocations only?
> 
> I didn't do it there since we didn't have reference to the "s_data"
> inside claim_allocations().
> 
> If I remember this right, only init_sched_groups_capacity() has the
> requirement to traverse the CPUs in reverse to do
> update_group_capacity() when we hit the first CPU in the group.
> It doesn't modify the "->ref" of any allocations.
> 
> I can put the claim_allocations() bits the previous loop and pass the
> CPU and the s_data reference so it can free both "d.sds" and all the
> "d.sd" bits in one place and retain this reverse loop for
> init_sched_groups_capacity(). Does that sound better?
> 

Yes.IMO Having it in one place is better.
Even the next loop could be used to do that.

>> sdt_alloc and free is complicated already.
>>
>>>            for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) {
>>>                claim_allocations(i, sd);
>>>                init_sched_groups_capacity(i, sd);
>>
>