From: Andi Kleen <ak@suse.de>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andrew Morton <akpm@osdl.org>, "Luck, Tony" <tony.luck@intel.com>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH: 003/017]Memory hotplug for new nodes v.4.(get node id at probe memory)
Date: Wed, 22 Mar 2006 13:17:55 +0000 [thread overview]
Message-ID: <200603221417.55462.ak@suse.de> (raw)
In-Reply-To: <20060317162835.C63D.Y-GOTO@jp.fujitsu.com>
On Friday 17 March 2006 09:20, Yasunori Goto wrote:
> When CONFIG_NUMA && CONFIG_ARCH_MEMORY_PROBE, nid should be defined
> before calling add_memory(nid, start, size).
Seems a bit weird to have the node number assignment somewhere
hidden in memory hotadd. It would be probably cleaner to have
a separate step for this.
> +#if defined(CONFIG_NUMA) && defined(CONFIG_ARCH_MEMORY_PROBE)
> +extern int arch_nid_probe(u64 start);
Instead of adding such ugly ifdefs better just add stubs to all the
architectures that support memory hotplug. There are not that many
anyways.
-Andi
> +#else
> +static inline int arch_nid_probe(u64 start)
> +{
> + return 0;
> +}
> +#endif
> +
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andrew Morton <akpm@osdl.org>, "Luck, Tony" <tony.luck@intel.com>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH: 003/017]Memory hotplug for new nodes v.4.(get node id at probe memory)
Date: Wed, 22 Mar 2006 14:17:55 +0100 [thread overview]
Message-ID: <200603221417.55462.ak@suse.de> (raw)
In-Reply-To: <20060317162835.C63D.Y-GOTO@jp.fujitsu.com>
On Friday 17 March 2006 09:20, Yasunori Goto wrote:
> When CONFIG_NUMA && CONFIG_ARCH_MEMORY_PROBE, nid should be defined
> before calling add_memory(nid, start, size).
Seems a bit weird to have the node number assignment somewhere
hidden in memory hotadd. It would be probably cleaner to have
a separate step for this.
> +#if defined(CONFIG_NUMA) && defined(CONFIG_ARCH_MEMORY_PROBE)
> +extern int arch_nid_probe(u64 start);
Instead of adding such ugly ifdefs better just add stubs to all the
architectures that support memory hotplug. There are not that many
anyways.
-Andi
> +#else
> +static inline int arch_nid_probe(u64 start)
> +{
> + return 0;
> +}
> +#endif
> +
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andrew Morton <akpm@osdl.org>, "Luck, Tony" <tony.luck@intel.com>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH: 003/017]Memory hotplug for new nodes v.4.(get node id at probe memory)
Date: Wed, 22 Mar 2006 14:17:55 +0100 [thread overview]
Message-ID: <200603221417.55462.ak@suse.de> (raw)
In-Reply-To: <20060317162835.C63D.Y-GOTO@jp.fujitsu.com>
On Friday 17 March 2006 09:20, Yasunori Goto wrote:
> When CONFIG_NUMA && CONFIG_ARCH_MEMORY_PROBE, nid should be defined
> before calling add_memory(nid, start, size).
Seems a bit weird to have the node number assignment somewhere
hidden in memory hotadd. It would be probably cleaner to have
a separate step for this.
> +#if defined(CONFIG_NUMA) && defined(CONFIG_ARCH_MEMORY_PROBE)
> +extern int arch_nid_probe(u64 start);
Instead of adding such ugly ifdefs better just add stubs to all the
architectures that support memory hotplug. There are not that many
anyways.
-Andi
> +#else
> +static inline int arch_nid_probe(u64 start)
> +{
> + return 0;
> +}
> +#endif
> +
--
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:[~2006-03-22 13:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 8:20 [PATCH: 003/017]Memory hotplug for new nodes v.4.(get node id at probe memory) Yasunori Goto
2006-03-17 8:20 ` Yasunori Goto
2006-03-17 8:20 ` Yasunori Goto
2006-03-22 13:17 ` Andi Kleen [this message]
2006-03-22 13:17 ` Andi Kleen
2006-03-22 13:17 ` Andi Kleen
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=200603221417.55462.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tony.luck@intel.com \
--cc=y-goto@jp.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 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.