From: Peter Zijlstra <peterz@infradead.org>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
mingo@redhat.com, miaox@cn.fujitsu.com,
linux-kernel@vger.kernel.org, linux-numa@vger.kernel.org
Subject: Re: [PATCH] Do not use cpu_to_node() to find an offlined cpu's node.
Date: Wed, 10 Oct 2012 11:51:34 +0200 [thread overview]
Message-ID: <1349862694.7880.114.camel@twins> (raw)
In-Reply-To: <507540F5.7040501@cn.fujitsu.com>
On Wed, 2012-10-10 at 17:33 +0800, Wen Congyang wrote:
>
> Hmm, if per-cpu memory is preserved, and we can't offline and remove
> this memory. So we can't offline the node.
>
> But, if the node is hot added, and per-cpu memory doesn't use the
> memory on this node. We can hotremove cpu/memory on this node, and then
> offline this node.
>
> Before the cpu is hotadded, cpu's node is -1. We set cpu<->node mapping
> when it is hotadded. So the entire cpu<->node mapping was not invariant
> during hotplug.
>
> So it is why I try to clear it when the cpu is hot-removed.
>
> As we need the mapping to migrate a task to the cpu on the same node first,
> I think we can clear the mapping when the node is offlined.
Hmm maybe, but hardware that can hot-add is rare and nobody has it so
nobody cares ;-)
But by clearing cpu_to_node on every hotplug you change semantics for
all hardware and everybody gets to feel the pain.
I'm not saying you cannot change things, I'm only saying you should be
far more careful about it, not change it and wait for things to break.
Put in some effort to find things that might break and warn people --
sure, you'll always miss some, and that's ok.
next prev parent reply other threads:[~2012-10-10 9:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 2:59 [PATCH] Do not use cpu_to_node() to find an offlined cpu's node Tang Chen
2012-10-09 6:21 ` David Rientjes
2012-10-09 8:34 ` Wen Congyang
2012-10-09 8:39 ` Tang Chen
2012-10-09 10:04 ` David Rientjes
2012-10-09 10:22 ` Wen Congyang
2012-10-09 20:00 ` David Rientjes
2012-10-09 10:57 ` Peter Zijlstra
2012-10-09 20:36 ` David Rientjes
2012-10-09 20:47 ` Peter Zijlstra
2012-10-09 23:27 ` David Rientjes
2012-10-10 2:06 ` Wen Congyang
2012-10-10 3:48 ` Wen Congyang
2012-10-10 9:10 ` Peter Zijlstra
2012-10-10 9:33 ` Wen Congyang
2012-10-10 9:51 ` Peter Zijlstra [this message]
2012-10-10 10:10 ` Wen Congyang
2012-10-10 10:07 ` Peter Zijlstra
2012-10-10 20:30 ` David Rientjes
2012-10-10 20:37 ` Andrew Morton
2012-10-10 20:57 ` David Rientjes
2012-10-18 0:52 ` David Rientjes
2012-10-18 2:51 ` Tang Chen
2012-10-18 3:29 ` David Rientjes
2012-10-19 11:18 ` Peter Zijlstra
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=1349862694.7880.114.camel@twins \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-numa@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
--cc=mingo@redhat.com \
--cc=rientjes@google.com \
--cc=tangchen@cn.fujitsu.com \
--cc=wency@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).