Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <74f1906e-fe58-c745-a851-b160374f7acf@redhat.com>
Date:   Mon, 10 Jul 2023 11:40:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PATCH] cgroup/cpuset: update parent subparts cpumask while
 holding css refcnt
Content-Language: en-US
To:     =?UTF-8?Q?Michal_Koutn=c3=bd?= <mkoutny@suse.com>,
        Miaohe Lin <linmiaohe@huawei.com>
Cc:     tj@kernel.org, hannes@cmpxchg.org, lizefan.x@bytedance.com,
        cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230701065049.1758266-1-linmiaohe@huawei.com>
 <fbabnjfly5w6fxrhe3eu6ebspngz2hd3tqs6rrbropcdvylnhs@ayjdpq73kwui>
From:   Waiman Long <longman@redhat.com>
In-Reply-To: <fbabnjfly5w6fxrhe3eu6ebspngz2hd3tqs6rrbropcdvylnhs@ayjdpq73kwui>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 7/10/23 11:11, Michal Koutný wrote:
> Hello.
>
> On Sat, Jul 01, 2023 at 02:50:49PM +0800, Miaohe Lin <linmiaohe@huawei.com> wrote:
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -1806,9 +1806,12 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
>>   		cpuset_for_each_child(cp, css, parent)
>>   			if (is_partition_valid(cp) &&
>>   			    cpumask_intersects(trialcs->cpus_allowed, cp->cpus_allowed)) {
>> +				if (!css_tryget_online(&cp->css))
>> +					continue;
>>   				rcu_read_unlock();
>>   				update_parent_subparts_cpumask(cp, partcmd_invalidate, NULL, &tmp);
>>   				rcu_read_lock();
>> +				css_put(&cp->css);
> Apologies for a possibly noob question -- why is RCU read lock
> temporarily dropped within the loop?
> (Is it only because of callback_lock or cgroup_file_kn_lock (via
> notify_partition_change()) on PREEMPT_RT?)
>
>
>
> [
> OT question:
> 	cpuset_for_each_child(cp, css, parent)				(1)
> 		if (is_partition_valid(cp) &&
> 		    cpumask_intersects(trialcs->cpus_allowed, cp->cpus_allowed)) {
> 			if (!css_tryget_online(&cp->css))
> 				continue;
> 			rcu_read_unlock();
> 			update_parent_subparts_cpumask(cp, partcmd_invalidate, NULL, &tmp);
> 			  ...
> 			  update_tasks_cpumask(cp->parent)
> 			    ...
> 			    css_task_iter_start(&cp->parent->css, 0, &it);	(2)
> 			      ...
> 			rcu_read_lock();
> 			css_put(&cp->css);
> 		}
>
> May this touch each task same number of times as its depth within
> herarchy?

I believe the primary reason is because update_parent_subparts_cpumask() 
can potential run for quite a while. So we don't want to hold the 
rcu_read_lock for too long. There may also be a potential that 
schedule() may be called.

Cheers,
Longman