Re: [PATCH -next] cgroup/cpuset: remove child_ecpus_count

[chenridong <chenridong@huawei.com>]

On 2024/7/24 10:16, Waiman Long wrote:
> On 7/23/24 21:08, Chen Ridong wrote:
>> The child_ecpus_count variable was previously used to update
>> sibling cpumask when parent's effective_cpus is updated. However, it 
>> became
>> obsolete after commit e2ffe502ba45 ("cgroup/cpuset: Add
>> cpuset.cpus.exclusive for v2"). It should be removed.
> Thanks for finding that.
>>
>> Signed-off-by: Chen Ridong <chenridong@huawei.com>
>> ---
>>   kernel/cgroup/cpuset.c | 13 -------------
>>   1 file changed, 13 deletions(-)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index 40ec4abaf440..146bf9258db2 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -188,10 +188,8 @@ struct cpuset {
>>       /*
>>        * Default hierarchy only:
>>        * use_parent_ecpus - set if using parent's effective_cpus
>> -     * child_ecpus_count - # of children with use_parent_ecpus set
>>        */
>>       int use_parent_ecpus;
>> -    int child_ecpus_count;
>>       /*
>>        * number of SCHED_DEADLINE tasks attached to this cpuset, so 
>> that we
>> @@ -1512,7 +1510,6 @@ static void reset_partition_data(struct cpuset *cs)
>>       if (!cpumask_and(cs->effective_cpus,
>>                parent->effective_cpus, cs->cpus_allowed)) {
>>           cs->use_parent_ecpus = true;
>> -        parent->child_ecpus_count++;
>>           cpumask_copy(cs->effective_cpus, parent->effective_cpus);
>>       }
>>   }
>> @@ -1689,10 +1686,7 @@ static int remote_partition_enable(struct 
>> cpuset *cs, int new_prs,
>>       isolcpus_updated = partition_xcpus_add(new_prs, NULL, 
>> tmp->new_cpus);
>>       list_add(&cs->remote_sibling, &remote_children);
>>       if (cs->use_parent_ecpus) {
>> -        struct cpuset *parent = parent_cs(cs);
>> -
>>           cs->use_parent_ecpus = false;
>> -        parent->child_ecpus_count--;
>>       }
> You can also remove { } or just set use_parent_ecpus to false.
>>       spin_unlock_irq(&callback_lock);
>>       update_unbound_workqueue_cpumask(isolcpus_updated);
>> @@ -2320,12 +2314,9 @@ static void update_cpumasks_hier(struct cpuset 
>> *cs, struct tmpmasks *tmp,
>>               cpumask_copy(tmp->new_cpus, parent->effective_cpus);
>>               if (!cp->use_parent_ecpus) {
>>                   cp->use_parent_ecpus = true;
>> -                parent->child_ecpus_count++;
>>               }
> Just set it to true.
>>           } else if (cp->use_parent_ecpus) {
>>               cp->use_parent_ecpus = false;
>> -            WARN_ON_ONCE(!parent->child_ecpus_count);
>> -            parent->child_ecpus_count--;
>>           }
> Remove {} or set it to false.
>>           if (remote)
>> @@ -4139,7 +4130,6 @@ static int cpuset_css_online(struct 
>> cgroup_subsys_state *css)
>>           cpumask_copy(cs->effective_cpus, parent->effective_cpus);
>>           cs->effective_mems = parent->effective_mems;
>>           cs->use_parent_ecpus = true;
>> -        parent->child_ecpus_count++;
>>       }
>>       spin_unlock_irq(&callback_lock);
>> @@ -4206,10 +4196,7 @@ static void cpuset_css_offline(struct 
>> cgroup_subsys_state *css)
>>           update_flag(CS_SCHED_LOAD_BALANCE, cs, 0);
>>       if (cs->use_parent_ecpus) {
>> -        struct cpuset *parent = parent_cs(cs);
>> -
>>           cs->use_parent_ecpus = false;
>> -        parent->child_ecpus_count--;
>>       }
> Just set it to false.
> 
> Cheers,
> Longman
> 
> 
> 

Thank you, Longman, I will do that.

I am considering the necessity of use_parent_ecpus. Currently, the 
use_parent_ecpus variable is only utilized within the 
update_sibling_cpumasks function. This implies that if a cpuset is not 
configured to use its parent's effective_cpus, it might not need to 
invoke update_cpumasks_hier. However, the invocation of 
update_cpumasks_hier may not be necessary for a cpuset, regardless of 
whether it uses its parent's effective_cpus, if there is no change in 
the cpuset's effective_cpus.

Is use_parent_ecpus still relevant?
Or, do I miss something?

Thanks
Ridong