From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [PATCH v2 08/10] cpuset: allow to keep tasks in empty cpusets
Date: Thu, 6 Jun 2013 18:26:46 +0800 [thread overview]
Message-ID: <51B063E6.30107@huawei.com> (raw)
In-Reply-To: <20130605205146.GI10693-9pTldWuhBndy/B6EtB590w@public.gmane.org>
On 2013/6/6 4:51, Tejun Heo wrote:
> Hello, Li.
>
> On Wed, Jun 05, 2013 at 05:16:59PM +0800, Li Zefan wrote:
>> @@ -2092,11 +2183,13 @@ static void cpuset_propagate_hotplug_workfn(struct work_struct *work)
>> mutex_unlock(&cpuset_mutex);
>>
>> /*
>> - * If @cs became empty, move tasks to the nearest ancestor with
>> - * execution resources. This is full cgroup operation which will
>> + * If sane_behavior flag is set, we'll keep tasks in empty cpusets.
>> + *
>> + * Otherwise move tasks to the nearest ancestor with execution
>> + * resources. This is full cgroup operation which will
>> * also call back into cpuset. Should be done outside any lock.
>> */
>> - if (is_empty)
>> + if (!sane && is_empty)
>> remove_tasks_in_empty_cpuset(cs);
>>
>> /* the following may free @cs, should be the last operation */
>> @@ -2171,6 +2264,7 @@ static void cpuset_hotplug_workfn(struct work_struct *work)
>> cpumask_copy(top_cpuset.cpus_allowed, &new_cpus);
>> mutex_unlock(&callback_mutex);
>> /* we don't mess with cpumasks of tasks in top_cpuset */
>> + update_tasks_cpumask_hier(&top_cpuset, false, NULL);
>> }
>
> I'm a little confused by the order of operation. We now have two
> different hierarchical walks for hotplug propagation, right? I
> suppose the above one is added because we now also need to update the
> mask when cpus are being brought online?
>
The first one will only update tasks in empty cpusets (no matter online or
offline), and the second one will only update tasks in non-empty cpusets
(only when offline).
> I wonder whether it'd be possible to merge the two paths. My
> suspicion is that we probably don't need propagate_hotplug_work
> anymore now that we can drop RCU read lock while doing the pre-order
> walk. What do you think?
>
It indeed can be confusing. I'll see if we can make the code clearer.
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Tejun Heo <tj@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH v2 08/10] cpuset: allow to keep tasks in empty cpusets
Date: Thu, 6 Jun 2013 18:26:46 +0800 [thread overview]
Message-ID: <51B063E6.30107@huawei.com> (raw)
In-Reply-To: <20130605205146.GI10693@mtj.dyndns.org>
On 2013/6/6 4:51, Tejun Heo wrote:
> Hello, Li.
>
> On Wed, Jun 05, 2013 at 05:16:59PM +0800, Li Zefan wrote:
>> @@ -2092,11 +2183,13 @@ static void cpuset_propagate_hotplug_workfn(struct work_struct *work)
>> mutex_unlock(&cpuset_mutex);
>>
>> /*
>> - * If @cs became empty, move tasks to the nearest ancestor with
>> - * execution resources. This is full cgroup operation which will
>> + * If sane_behavior flag is set, we'll keep tasks in empty cpusets.
>> + *
>> + * Otherwise move tasks to the nearest ancestor with execution
>> + * resources. This is full cgroup operation which will
>> * also call back into cpuset. Should be done outside any lock.
>> */
>> - if (is_empty)
>> + if (!sane && is_empty)
>> remove_tasks_in_empty_cpuset(cs);
>>
>> /* the following may free @cs, should be the last operation */
>> @@ -2171,6 +2264,7 @@ static void cpuset_hotplug_workfn(struct work_struct *work)
>> cpumask_copy(top_cpuset.cpus_allowed, &new_cpus);
>> mutex_unlock(&callback_mutex);
>> /* we don't mess with cpumasks of tasks in top_cpuset */
>> + update_tasks_cpumask_hier(&top_cpuset, false, NULL);
>> }
>
> I'm a little confused by the order of operation. We now have two
> different hierarchical walks for hotplug propagation, right? I
> suppose the above one is added because we now also need to update the
> mask when cpus are being brought online?
>
The first one will only update tasks in empty cpusets (no matter online or
offline), and the second one will only update tasks in non-empty cpusets
(only when offline).
> I wonder whether it'd be possible to merge the two paths. My
> suspicion is that we probably don't need propagate_hotplug_work
> anymore now that we can drop RCU read lock while doing the pre-order
> walk. What do you think?
>
It indeed can be confusing. I'll see if we can make the code clearer.
next prev parent reply other threads:[~2013-06-06 10:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 9:14 [PATCH v2 00/10] cpuset: implement sane hierarchy behaviors Li Zefan
2013-06-05 9:14 ` Li Zefan
[not found] ` <51AF0183.8070602-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-06-05 9:15 ` [PATCH v2 01/10] cpuset: remove redundant check in cpuset_cpus_allowed_fallback() Li Zefan
2013-06-05 9:15 ` Li Zefan
2013-06-05 9:15 ` [PATCH v2 02/10] cpuset: cleanup guarantee_online_{cpus|mems}() Li Zefan
2013-06-05 9:15 ` Li Zefan
2013-06-05 9:15 ` Li Zefan
2013-06-05 9:15 ` [PATCH v2 03/10] cpuset: remove unnecessary variable in cpuset_attach() Li Zefan
2013-06-05 9:15 ` Li Zefan
2013-06-05 9:15 ` Li Zefan
2013-06-05 9:15 ` [PATCH v2 04/10] cpuset: remove cpuset_test_cpumask() Li Zefan
2013-06-05 9:15 ` Li Zefan
2013-06-05 9:15 ` [PATCH v2 05/10] cpuset: re-structure update_cpumask() a bit Li Zefan
2013-06-05 9:15 ` Li Zefan
[not found] ` <51AF01CF.1070706-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-06-05 20:57 ` Tejun Heo
2013-06-05 20:57 ` Tejun Heo
2013-06-05 9:16 ` [PATCH v2 06/10] cpuset: record old_mems_allowed in struct cpuset Li Zefan
2013-06-05 9:16 ` Li Zefan
[not found] ` <51AF01E8.8080205-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-06-05 19:45 ` Tejun Heo
2013-06-05 19:45 ` Tejun Heo
[not found] ` <20130605194522.GG10693-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2013-06-06 9:58 ` Li Zefan
2013-06-06 9:58 ` Li Zefan
2013-06-05 9:16 ` [PATCH v2 07/10] cpuset: introduce effective_{cpumask|nodemask}_cpuset() Li Zefan
2013-06-05 9:16 ` Li Zefan
2013-06-05 9:16 ` [PATCH v2 08/10] cpuset: allow to keep tasks in empty cpusets Li Zefan
2013-06-05 9:16 ` Li Zefan
[not found] ` <51AF020B.3030701-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-06-05 20:51 ` Tejun Heo
2013-06-05 20:51 ` Tejun Heo
[not found] ` <20130605205146.GI10693-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2013-06-06 10:26 ` Li Zefan
2013-06-06 10:26 ` Li Zefan [this message]
2013-06-06 10:26 ` Li Zefan
[not found] ` <51B063E6.30107-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-06-06 21:24 ` Tejun Heo
2013-06-06 21:24 ` Tejun Heo
2013-06-06 21:24 ` Tejun Heo
2013-06-05 9:17 ` [PATCH v2 09/10] cpuset: allow to move tasks to " Li Zefan
2013-06-05 9:17 ` Li Zefan
2013-06-05 9:17 ` [PATCH v2 10/10] cpuset: fix to migrate mm correctly in a corner case Li Zefan
2013-06-05 9:17 ` Li Zefan
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=51B063E6.30107@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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.