All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Qais Yousef <qyousef@layalina.io>,
	Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>, Hao Luo <haoluo@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, luca.abeni@santannapisa.it,
	claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it,
	bristot@redhat.com, mathieu.poirier@linaro.org,
	cgroups@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Wei Wang <wvw@google.com>, Rick Yiu <rickyiu@google.com>,
	Quentin Perret <qperret@google.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH 5/6] cgroup/cpuset: Free DL BW in case can_attach() fails
Date: Thu, 30 Mar 2023 12:13:02 -0400	[thread overview]
Message-ID: <3268bedc-ee36-519a-de37-3c366129baae@redhat.com> (raw)
In-Reply-To: <5ff103f9-1366-0a9b-bd97-419ced1de07f@arm.com>

On 3/30/23 11:14, Dietmar Eggemann wrote:
> On 29/03/2023 20:09, Waiman Long wrote:
>> On 3/29/23 12:39, Dietmar Eggemann wrote:
>>> On 29/03/2023 16:31, Waiman Long wrote:
>>>> On 3/29/23 10:25, Waiman Long wrote:
>>>>> On 3/29/23 08:55, Juri Lelli wrote:
>>>>>> From: Dietmar Eggemann <dietmar.eggemann@arm.com>
>>> [...]
>>>
>>>>>> @@ -2518,11 +2547,21 @@ static int cpuset_can_attach(struct
>>>>>> cgroup_taskset *tset)
>>>>>>     static void cpuset_cancel_attach(struct cgroup_taskset *tset)
>>>>>>     {
>>>>>>         struct cgroup_subsys_state *css;
>>>>>> +    struct cpuset *cs;
>>>>>>           cgroup_taskset_first(tset, &css);
>>>>>> +    cs = css_cs(css);
>>>>>>           mutex_lock(&cpuset_mutex);
>>>>>> -    css_cs(css)->attach_in_progress--;
>>>>>> +    cs->attach_in_progress--;
>>>>>> +
>>>>>> +    if (cs->nr_migrate_dl_tasks) {
>>>>>> +        int cpu = cpumask_any(cs->effective_cpus);
>>>>>> +
>>>>>> +        dl_bw_free(cpu, cs->sum_migrate_dl_bw);
>>>>>> +        reset_migrate_dl_data(cs);
>>>>>> +    }
>>>>>> +
>>>> Another nit that I have is that you may have to record also the cpu
>>>> where the DL bandwidth is allocated in cpuset_can_attach() and free the
>>>> bandwidth back into that cpu or there can be an underflow if another cpu
>>>> is chosen.
>>> Many thanks for the review!
>>>
>>> But isn't the DL BW control `struct dl_bw` per `struct root_domain`
>>> which is per exclusive cpuset. So as long cpu is from
>>> `cs->effective_cpus` shouldn't this be fine?
>> Sorry for my ignorance on how the deadline bandwidth operation work. I
>> check the bandwidth code and find that we are storing the bandwidth
>> information in the root domain, not on the cpu. That shouldn't be a
>> concern then.
>>
>> However, I still have some question on how that works when dealing with
>> cpuset. First of all, not all the CPUs in a given root domains are in
>> the cpuset. So there may be enough bandwidth on the root domain, but it
>> doesn't mean there will be enough bandwidth in the set of CPUs in a
>> particular cpuset. Secondly, how do you deal with isolated CPUs that do
>> not have a corresponding root domain? It is now possible to create a
>> cpuset with isolated CPUs.
> Sorry, I overlooked this email somehow.
>
> IMHO, this is only done for exclusive cpusets:
>
>    cpuset_can_attach()
>
>      if (!cpumask_intersects(oldcs->effective_cpus, cs->effective_cpus))
>
> So they should have their own root_domain congruent to their cpumask.

I am sorry that I missed that check.

Parallel attach is actually an existing problem in cpuset as there is a 
shared cpuset_attach_old_cs variable being used by cpuset between 
cpuset_can_attach() and cpuset_attach(). So any parallel attach can lead 
to corruption of this common data causing incorrect result. So this 
problem is not specific to this patch series. So please ignore this 
patch for now. It has to be addressed separately.

Cheers,
Longman


WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Dietmar Eggemann <dietmar.eggemann-5wv7dgnIgG8@public.gmane.org>,
	Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Qais Yousef <qyousef-wp2msK0BRk8tq7phqP6ubQ@public.gmane.org>,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Hao Luo <haoluo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	luca.abeni-5rdYK369eBLQB0XuIGIEkQ@public.gmane.org,
	claudio-YOzL5CV4y4YG1A2ADO40+w@public.gmane.org,
	tommaso.cucinotta-5rdYK369eBLQB0XuIGIEkQ@public.gmane.org,
	bristot-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Vincent Guittot
	<vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Wei Wang <wvw-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Rick Yiu <rickyiu-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Quentin Perret <qperret-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Heiko Carstens <hca-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
	Vasily Gorbik <gor-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
	Alexander Gordeev
	<agordeev-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
	Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 5/6] cgroup/cpuset: Free DL BW in case can_attach() fails
Date: Thu, 30 Mar 2023 12:13:02 -0400	[thread overview]
Message-ID: <3268bedc-ee36-519a-de37-3c366129baae@redhat.com> (raw)
In-Reply-To: <5ff103f9-1366-0a9b-bd97-419ced1de07f-5wv7dgnIgG8@public.gmane.org>

On 3/30/23 11:14, Dietmar Eggemann wrote:
> On 29/03/2023 20:09, Waiman Long wrote:
>> On 3/29/23 12:39, Dietmar Eggemann wrote:
>>> On 29/03/2023 16:31, Waiman Long wrote:
>>>> On 3/29/23 10:25, Waiman Long wrote:
>>>>> On 3/29/23 08:55, Juri Lelli wrote:
>>>>>> From: Dietmar Eggemann <dietmar.eggemann-5wv7dgnIgG8@public.gmane.org>
>>> [...]
>>>
>>>>>> @@ -2518,11 +2547,21 @@ static int cpuset_can_attach(struct
>>>>>> cgroup_taskset *tset)
>>>>>>     static void cpuset_cancel_attach(struct cgroup_taskset *tset)
>>>>>>     {
>>>>>>         struct cgroup_subsys_state *css;
>>>>>> +    struct cpuset *cs;
>>>>>>           cgroup_taskset_first(tset, &css);
>>>>>> +    cs = css_cs(css);
>>>>>>           mutex_lock(&cpuset_mutex);
>>>>>> -    css_cs(css)->attach_in_progress--;
>>>>>> +    cs->attach_in_progress--;
>>>>>> +
>>>>>> +    if (cs->nr_migrate_dl_tasks) {
>>>>>> +        int cpu = cpumask_any(cs->effective_cpus);
>>>>>> +
>>>>>> +        dl_bw_free(cpu, cs->sum_migrate_dl_bw);
>>>>>> +        reset_migrate_dl_data(cs);
>>>>>> +    }
>>>>>> +
>>>> Another nit that I have is that you may have to record also the cpu
>>>> where the DL bandwidth is allocated in cpuset_can_attach() and free the
>>>> bandwidth back into that cpu or there can be an underflow if another cpu
>>>> is chosen.
>>> Many thanks for the review!
>>>
>>> But isn't the DL BW control `struct dl_bw` per `struct root_domain`
>>> which is per exclusive cpuset. So as long cpu is from
>>> `cs->effective_cpus` shouldn't this be fine?
>> Sorry for my ignorance on how the deadline bandwidth operation work. I
>> check the bandwidth code and find that we are storing the bandwidth
>> information in the root domain, not on the cpu. That shouldn't be a
>> concern then.
>>
>> However, I still have some question on how that works when dealing with
>> cpuset. First of all, not all the CPUs in a given root domains are in
>> the cpuset. So there may be enough bandwidth on the root domain, but it
>> doesn't mean there will be enough bandwidth in the set of CPUs in a
>> particular cpuset. Secondly, how do you deal with isolated CPUs that do
>> not have a corresponding root domain? It is now possible to create a
>> cpuset with isolated CPUs.
> Sorry, I overlooked this email somehow.
>
> IMHO, this is only done for exclusive cpusets:
>
>    cpuset_can_attach()
>
>      if (!cpumask_intersects(oldcs->effective_cpus, cs->effective_cpus))
>
> So they should have their own root_domain congruent to their cpumask.

I am sorry that I missed that check.

Parallel attach is actually an existing problem in cpuset as there is a 
shared cpuset_attach_old_cs variable being used by cpuset between 
cpuset_can_attach() and cpuset_attach(). So any parallel attach can lead 
to corruption of this common data causing incorrect result. So this 
problem is not specific to this patch series. So please ignore this 
patch for now. It has to be addressed separately.

Cheers,
Longman


  reply	other threads:[~2023-03-30 16:14 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 12:55 [PATCH 0/6] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Juri Lelli
2023-03-29 12:55 ` Juri Lelli
2023-03-29 12:55 ` [PATCH 1/6] cgroup/cpuset: Rename functions dealing with DEADLINE accounting Juri Lelli
2023-03-29 12:55   ` Juri Lelli
2023-04-04 20:05   ` Qais Yousef
2023-04-04 20:05     ` Qais Yousef
2023-03-29 12:55 ` [PATCH 2/6] sched/cpuset: Bring back cpuset_mutex Juri Lelli
2023-03-29 12:55   ` Juri Lelli
2023-04-04 17:31   ` Waiman Long
2023-04-04 17:31     ` Waiman Long
2023-04-26 11:57     ` Juri Lelli
2023-04-26 11:57       ` Juri Lelli
2023-04-26 14:05       ` Waiman Long
2023-04-26 14:05         ` Waiman Long
2023-04-27  2:58         ` Xuewen Yan
2023-04-27  2:58           ` Xuewen Yan
2023-04-27  5:53           ` Juri Lelli
2023-04-27  5:53             ` Juri Lelli
2023-04-27 11:50             ` Xuewen Yan
2023-04-27 11:50               ` Xuewen Yan
2023-04-28 11:22             ` Qais Yousef
2023-04-28 11:22               ` Qais Yousef
2023-04-26 14:31       ` Daniel Bristot de Oliveira
2023-04-26 14:31         ` Daniel Bristot de Oliveira
2023-04-04 20:05   ` Qais Yousef
2023-04-04 20:05     ` Qais Yousef
2023-03-29 12:55 ` [PATCH 3/6] sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets Juri Lelli
2023-04-04 20:06   ` Qais Yousef
2023-04-04 20:06     ` Qais Yousef
2023-10-09 11:43   ` Xia Fukun
2023-10-09 15:26     ` Waiman Long
2023-03-29 12:55 ` [PATCH 4/6] sched/deadline: Create DL BW alloc, free & check overflow interface Juri Lelli
2023-03-29 12:55   ` Juri Lelli
2023-03-29 14:24   ` Waiman Long
2023-03-29 14:24     ` Waiman Long
2023-03-29 12:55 ` [PATCH 5/6] cgroup/cpuset: Free DL BW in case can_attach() fails Juri Lelli
2023-03-29 12:55   ` Juri Lelli
2023-03-29 14:25   ` Waiman Long
2023-03-29 14:31     ` Waiman Long
2023-03-29 14:31       ` Waiman Long
2023-03-29 16:39       ` Dietmar Eggemann
2023-03-29 16:39         ` Dietmar Eggemann
2023-03-29 18:09         ` Waiman Long
2023-03-29 18:09           ` Waiman Long
2023-03-30 15:14           ` Dietmar Eggemann
2023-03-30 15:14             ` Dietmar Eggemann
2023-03-30 16:13             ` Waiman Long [this message]
2023-03-30 16:13               ` Waiman Long
2023-03-29 12:55 ` [PATCH 6/6] cgroup/cpuset: Iterate only if DEADLINE tasks are present Juri Lelli
2023-03-29 12:55   ` Juri Lelli
2023-04-04 20:06   ` Qais Yousef
2023-04-04 20:06     ` Qais Yousef
2023-04-26 11:58     ` Juri Lelli
2023-04-26 11:58       ` Juri Lelli
2023-03-29 14:34 ` [PATCH 0/6] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Waiman Long
2023-03-29 14:34   ` Waiman Long
2023-03-29 16:02 ` [PATCH 6/7] cgroup/cpuset: Protect DL BW data against parallel cpuset_attach() Waiman Long
2023-03-29 16:02   ` Waiman Long
2023-03-29 16:05   ` Waiman Long
2023-03-30 13:34   ` Dietmar Eggemann
2023-03-30 13:34     ` Dietmar Eggemann
2023-04-04 20:09 ` [PATCH 0/6] sched/deadline: cpuset: Rework DEADLINE bandwidth restoration Qais Yousef
2023-04-04 20:09   ` Qais Yousef
2023-04-18 14:11 ` Qais Yousef
2023-04-18 14:11   ` Qais Yousef
2023-04-18 14:31   ` Waiman Long
2023-04-18 14:31     ` Waiman Long
2023-04-20 14:15     ` Juri Lelli
2023-04-20 14:15       ` Juri Lelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3268bedc-ee36-519a-de37-3c366129baae@redhat.com \
    --to=longman@redhat.com \
    --cc=agordeev@linux.ibm.com \
    --cc=bristot@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=claudio@evidence.eu.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gor@linux.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=haoluo@google.com \
    --cc=hca@linux.ibm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=luca.abeni@santannapisa.it \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=qyousef@layalina.io \
    --cc=rickyiu@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sudeep.holla@arm.com \
    --cc=tj@kernel.org \
    --cc=tommaso.cucinotta@santannapisa.it \
    --cc=vincent.guittot@linaro.org \
    --cc=wvw@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.