LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
Al Viro <viro@ZenIV.linux.org.uk>,
Al Viro <viro@ftp.linux.org.uk>,
linux-kernel@vger.kernel.org, jgarzik@pobox.com
Subject: Re: [PATCH] el3_common_init() should be __devinit, not __init
Date: Sun, 2 Nov 2008 21:31:56 +0100 [thread overview]
Message-ID: <20081102203156.GC4330@uranus.ravnborg.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0811021008060.3483@nehalem.linux-foundation.org>
On Sun, Nov 02, 2008 at 10:13:03AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 1 Nov 2008, Sam Ravnborg wrote:
> >
> > For cpuinit/cpuexit the gain turned out to be minimal.
>
> Quite frankly, I'm not convinced.
>
> Yeah, yeah, most distro's end up always enabling CPU hotplug due to
> suspend/resume, but:
>
> - desktop PC's aren't where most memory pressures are anyway
>
> - on UP, CONFIG_HOTPLUG_CPU isn't on even if you do have suspend/resume
>
> - we should still care about embedded devices, and while some of them are
> growing up (and having SMP and not caring about a few tens of kB of
> memory), I don't think that's a valid argument for the other ones.
I benchmarked by investigating a common arm config and not some bloated
x86 desktop config when analysing the cpuinit/cpuexit case.
Another reason why I like to see cpuinit dropped is that it is misused
all over. __cpuinit are used for two purposes:
- to annotate code/data that is only used in the early init phase if
HOTPLUG_CPU is not enabled
- to annotate code/data that is only used if HOTPLUG_CPU is enabled
The latter use is plain wrong but I never managed to really get to
the bottom of it.
If we could use our config ssytem in the normals ways to cover
with code that is only used for HOTPLUG_CPU then things would be
much simpler.
When I have done sweep fixing all section mismatchs it has almost
always been cpuinit that has caused me most troubles.
The others has been trivial to deal with.
As Al points out in his reply a full day effort can fix a lot
of the remaining ones.
For devinit/devexit there is in my mind no questions that they
shall remain.
The most important topic to address is to get better detection.
What we can do in modpost is limited :-(
Sam
next prev parent reply other threads:[~2008-11-02 20:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-01 18:20 Al Viro
2008-11-01 19:12 ` Alexey Dobriyan
2008-11-01 19:16 ` Al Viro
2008-11-01 19:27 ` Alexey Dobriyan
2008-11-01 19:32 ` Al Viro
2008-11-01 21:17 ` Sam Ravnborg
2008-11-02 18:13 ` Linus Torvalds
2008-11-02 18:47 ` Al Viro
2008-11-02 20:31 ` Sam Ravnborg [this message]
2008-11-06 5:42 ` Jeff Garzik
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=20081102203156.GC4330@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=adobriyan@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=viro@ftp.linux.org.uk \
--subject='Re: [PATCH] el3_common_init() should be __devinit, not __init' \
/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
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).