From: Paul Mundt <lethal@linux-sh.org>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Sam Ravnborg <sam@ravnborg.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: mm: memory/cpu hotplug section mismatch.
Date: Tue, 12 Jun 2007 12:19:12 +0900 [thread overview]
Message-ID: <20070612031912.GA1377@linux-sh.org> (raw)
In-Reply-To: <20070612102236.E8BA.Y-GOTO@jp.fujitsu.com>
On Tue, Jun 12, 2007 at 10:50:33AM +0900, Yasunori Goto wrote:
> > >
> > > If CONFIG_MEMORY_HOTPLUG=n __meminit == __init, and if
> > > CONFIG_HOTPLUG_CPU=n __cpuinit == __init. However, with one set and the
> > > other disabled, you end up with a reference between __init and a regular
> > > non-init function.
> >
> > My plan is to define dedicated sections for both __devinit and __meminit.
> > Then we can apply the checks no matter the definition of CONFIG_HOTPLUG*
>
> I prefer defining "__nodeinit" for __cpuinit and __meminit case to
> __devinit. __devinit is used many devices like I/O, and it is
> useful for many desktop users. But, cpu/memory hotpluggable box
> is very rare. And it should be in init section for many people.
>
> This kind of issue is caused by initialization of pgdat/zone.
> I think __nodeinit is enough and desirable.
>
A #define __nodeinit __devinit is probably reasonable for clarity
purposes. But whatever we want to call it, the current __cpuinit for
zone_batchsize() has to be changed, as it will be freed with the rest of
the init code if CPU hotplug is disabled. If we want to do something
cleaner in the long run, that's fine, but changing to __devinit now at
least gets the semantics right for both the memory and cpu hotplug cases.
--
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>
prev parent reply other threads:[~2007-06-12 3:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 4:35 Paul Mundt
2007-06-11 5:01 ` KAMEZAWA Hiroyuki
2007-06-11 5:09 ` Paul Mundt
2007-06-11 15:27 ` Randy Dunlap
2007-06-11 15:44 ` Paul Mundt
2007-06-11 18:40 ` Sam Ravnborg
2007-06-12 1:50 ` Yasunori Goto
2007-06-12 3:19 ` Paul Mundt [this message]
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=20070612031912.GA1377@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=randy.dunlap@oracle.com \
--cc=sam@ravnborg.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox