From: Miao Xie <miaox@cn.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>,
Nick Piggin <npiggin@suse.de>, Paul Menage <menage@google.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH V2 1/4] cpuset: fix the problem that cpuset_mem_spread_node() returns an offline node
Date: Tue, 09 Mar 2010 09:25:13 +0800 [thread overview]
Message-ID: <4B95A379.4000207@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1003081318460.14689@chino.kir.corp.google.com>
on 2010-3-9 5:22, David Rientjes wrote:
> On Mon, 8 Mar 2010, Miao Xie wrote:
>
>> Changes from V1 to V2:
>> - cleanup two unnecessary smp_wmb() at cpuset_migrate_mm()
>>
>
> This patch is already in -mm without this update, so it's probably better
> to make this an incremental series basedo n mmotm-2010-03-04-18-05 or
> later.
ok, I'll do it.
>
>> @@ -2090,15 +2086,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;
>> +
>> cgroup_lock();
>> switch (action) {
>> case MEM_ONLINE:
>> - case MEM_OFFLINE:
>> + oldmems = top_cpuset.mems_allowed;
>> mutex_lock(&callback_mutex);
>> top_cpuset.mems_allowed = node_states[N_HIGH_MEMORY];
>> mutex_unlock(&callback_mutex);
>> - if (action == MEM_OFFLINE)
>> - scan_for_empty_cpusets(&top_cpuset);
>> + update_tasks_nodemask(&top_cpuset, &oldmems, NULL);
>> + break;
>> + case MEM_OFFLINE:
>> + scan_for_empty_cpusets(&top_cpuset);
>> break;
>> default:
>> break;
>
> This looks wrong, why isn't top_cpuset.mems_allowed updated for
> MEM_OFFLINE? If you're going to update it when a new node comes online
> for (struct memory_notify *)arg->status_change_nid is >= 0, then it should
> be removed from the nodemask when offlined as well. You'd be calling
> scan_for_empty_cpusets() needlessly in this code since it'll never change
> under your hotplug code.
scan_for_empty_cpusets() will update top_cpuset.mems_allowed when doing MEM_OFFLINE.
The comment of this source is necessary. I'll add it.
Thanks!
Miao
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Miao Xie <miaox@cn.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>,
Nick Piggin <npiggin@suse.de>, Paul Menage <menage@google.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH V2 1/4] cpuset: fix the problem that cpuset_mem_spread_node() returns an offline node
Date: Tue, 09 Mar 2010 09:25:13 +0800 [thread overview]
Message-ID: <4B95A379.4000207@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1003081318460.14689@chino.kir.corp.google.com>
on 2010-3-9 5:22, David Rientjes wrote:
> On Mon, 8 Mar 2010, Miao Xie wrote:
>
>> Changes from V1 to V2:
>> - cleanup two unnecessary smp_wmb() at cpuset_migrate_mm()
>>
>
> This patch is already in -mm without this update, so it's probably better
> to make this an incremental series basedo n mmotm-2010-03-04-18-05 or
> later.
ok, I'll do it.
>
>> @@ -2090,15 +2086,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;
>> +
>> cgroup_lock();
>> switch (action) {
>> case MEM_ONLINE:
>> - case MEM_OFFLINE:
>> + oldmems = top_cpuset.mems_allowed;
>> mutex_lock(&callback_mutex);
>> top_cpuset.mems_allowed = node_states[N_HIGH_MEMORY];
>> mutex_unlock(&callback_mutex);
>> - if (action == MEM_OFFLINE)
>> - scan_for_empty_cpusets(&top_cpuset);
>> + update_tasks_nodemask(&top_cpuset, &oldmems, NULL);
>> + break;
>> + case MEM_OFFLINE:
>> + scan_for_empty_cpusets(&top_cpuset);
>> break;
>> default:
>> break;
>
> This looks wrong, why isn't top_cpuset.mems_allowed updated for
> MEM_OFFLINE? If you're going to update it when a new node comes online
> for (struct memory_notify *)arg->status_change_nid is >= 0, then it should
> be removed from the nodemask when offlined as well. You'd be calling
> scan_for_empty_cpusets() needlessly in this code since it'll never change
> under your hotplug code.
scan_for_empty_cpusets() will update top_cpuset.mems_allowed when doing MEM_OFFLINE.
The comment of this source is necessary. I'll add it.
Thanks!
Miao
>
>
--
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-03-09 1:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-08 10:03 [PATCH V2 1/4] cpuset: fix the problem that cpuset_mem_spread_node() returns an offline node Miao Xie
2010-03-08 10:03 ` Miao Xie
2010-03-08 21:22 ` David Rientjes
2010-03-08 21:22 ` David Rientjes
2010-03-09 1:25 ` Miao Xie [this message]
2010-03-09 1:25 ` Miao Xie
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=4B95A379.4000207@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=menage@google.com \
--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.