[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0c685c5e-bb9d-4b96-8cce-1be1bca59059@huawei.com>
Date: Wed, 24 Jul 2024 10:44:26 +0800
From: chenridong <chenridong@...wei.com>
To: Waiman Long <longman@...hat.com>, <tj@...nel.org>,
<lizefan.x@...edance.com>, <hannes@...xchg.org>, <adityakali@...gle.com>,
<sergeh@...nel.org>, <mkoutny@...e.com>
CC: <cgroups@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next] cgroup/cpuset: remove child_ecpus_count
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@...wei.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
Powered by blists - more mailing lists