From: Miao Xie <miaox@cn.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2)
Date: Tue, 23 Feb 2010 15:32:32 +0800 [thread overview]
Message-ID: <4B838490.1050908@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1002221339160.14426@chino.kir.corp.google.com>
on 2010-2-23 6:06, David Rientjes wrote:
>>>> Right, but the callback_mutex was being removed by this patch.
>>>>
>>>
>>> I was making the case for it to be readded :)
>>
>> But cgroup_mutex is held when someone changes cs->cpus_allowed or doing hotplug,
>> so I think callback_mutex is not necessary in this case.
>>
>
> Then why is it taken in update_cpumask()?
when we read cs->cpus_allowed, we need just hold one of callback_mutex and cgroup_mutex.
If we want to change cs->cpus_allowed, we must hold callback_mutex and cgroup_mutex.
>> /*
>> @@ -1391,11 +1393,10 @@ static void cpuset_attach(struct cgroup_subsys *ss, struct cgroup *cont,
>>
>> if (cs == &top_cpuset) {
>> cpumask_copy(cpus_attach, cpu_possible_mask);
>> - to = node_possible_map;
>> } else {
>> guarantee_online_cpus(cs, cpus_attach);
>> - guarantee_online_mems(cs, &to);
>> }
>> + guarantee_online_mems(cs, &to);
>>
>> /* do per-task migration stuff possibly for each in the threadgroup */
>> cpuset_attach_task(tsk, &to, cs);
>
> Do we need to set cpus_attach to cpu_possible_mask? Why won't
> cpu_active_mask suffice?
If we set cpus_attach to cpu_possible_mask, we needn't do anything for tasks in the top_cpuset when
doing cpu hotplug. If not, we will update cpus_allowed of all tasks in the top_cpuset.
>
>> @@ -2090,15 +2091,19 @@ static int cpuset_track_online_cpus(struct notifier_block *unused_nb,
>> static int cpuset_track_online_nodes(struct notifier_block *self,
>> unsigned long action, void *arg)
>> {
>> + nodemask_t oldmems;
>
> Is it possible to use NODEMASK_ALLOC() instead?
Yes. I will write another patch to fix it.(These are the same problems in the other functions)
WARNING: multiple messages have this Message-ID (diff)
From: Miao Xie <miaox@cn.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2)
Date: Tue, 23 Feb 2010 15:32:32 +0800 [thread overview]
Message-ID: <4B838490.1050908@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1002221339160.14426@chino.kir.corp.google.com>
on 2010-2-23 6:06, David Rientjes wrote:
>>>> Right, but the callback_mutex was being removed by this patch.
>>>>
>>>
>>> I was making the case for it to be readded :)
>>
>> But cgroup_mutex is held when someone changes cs->cpus_allowed or doing hotplug,
>> so I think callback_mutex is not necessary in this case.
>>
>
> Then why is it taken in update_cpumask()?
when we read cs->cpus_allowed, we need just hold one of callback_mutex and cgroup_mutex.
If we want to change cs->cpus_allowed, we must hold callback_mutex and cgroup_mutex.
>> /*
>> @@ -1391,11 +1393,10 @@ static void cpuset_attach(struct cgroup_subsys *ss, struct cgroup *cont,
>>
>> if (cs == &top_cpuset) {
>> cpumask_copy(cpus_attach, cpu_possible_mask);
>> - to = node_possible_map;
>> } else {
>> guarantee_online_cpus(cs, cpus_attach);
>> - guarantee_online_mems(cs, &to);
>> }
>> + guarantee_online_mems(cs, &to);
>>
>> /* do per-task migration stuff possibly for each in the threadgroup */
>> cpuset_attach_task(tsk, &to, cs);
>
> Do we need to set cpus_attach to cpu_possible_mask? Why won't
> cpu_active_mask suffice?
If we set cpus_attach to cpu_possible_mask, we needn't do anything for tasks in the top_cpuset when
doing cpu hotplug. If not, we will update cpus_allowed of all tasks in the top_cpuset.
>
>> @@ -2090,15 +2091,19 @@ static int cpuset_track_online_cpus(struct notifier_block *unused_nb,
>> static int cpuset_track_online_nodes(struct notifier_block *self,
>> unsigned long action, void *arg)
>> {
>> + nodemask_t oldmems;
>
> Is it possible to use NODEMASK_ALLOC() instead?
Yes. I will write another patch to fix it.(These are the same problems in the other functions)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-02-23 7:33 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 13:49 [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2) Nick Piggin
2010-02-18 13:49 ` Nick Piggin
2010-02-18 21:38 ` David Rientjes
2010-02-18 21:38 ` David Rientjes
2010-02-19 3:31 ` Nick Piggin
2010-02-19 3:31 ` Nick Piggin
2010-02-19 10:06 ` David Rientjes
2010-02-19 10:06 ` David Rientjes
2010-02-22 11:53 ` Miao Xie
2010-02-22 11:53 ` Miao Xie
2010-02-22 12:06 ` Nick Piggin
2010-02-22 12:06 ` Nick Piggin
2010-02-23 1:48 ` Miao Xie
2010-02-23 1:48 ` Miao Xie
2010-02-22 22:06 ` David Rientjes
2010-02-22 22:06 ` David Rientjes
2010-02-23 7:32 ` Miao Xie [this message]
2010-02-23 7:32 ` Miao Xie
2010-02-23 8:55 ` David Rientjes
2010-02-23 8:55 ` David Rientjes
2010-02-23 9:23 ` Miao Xie
2010-02-23 9:23 ` Miao Xie
2010-02-23 22:31 ` David Rientjes
2010-02-23 22:31 ` David Rientjes
2010-02-24 9:35 ` Miao Xie
2010-02-24 9:35 ` Miao Xie
2010-02-24 21:08 ` David Rientjes
2010-02-24 21:08 ` David Rientjes
2010-02-25 1:18 ` Miao Xie
2010-02-25 1:18 ` Miao Xie
2010-02-22 12:12 ` Nick Piggin
2010-02-22 12:12 ` Nick Piggin
2010-02-22 22:00 ` David Rientjes
2010-02-22 22:00 ` David Rientjes
2010-02-23 8:25 ` Miao Xie
2010-02-23 8:25 ` Miao Xie
2010-02-23 8:44 ` David Rientjes
2010-02-23 8:44 ` David Rientjes
2010-02-24 9:49 ` Miao Xie
2010-02-24 9:49 ` Miao Xie
2010-02-24 21:06 ` David Rientjes
2010-02-24 21:06 ` David Rientjes
2010-02-19 7:51 ` KOSAKI Motohiro
2010-02-19 7:51 ` KOSAKI Motohiro
2010-02-19 9:42 ` David Rientjes
2010-02-19 9:42 ` David Rientjes
2010-02-19 7:56 ` KAMEZAWA Hiroyuki
2010-02-19 7:56 ` KAMEZAWA Hiroyuki
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=4B838490.1050908@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=rientjes@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.