From: Sam Ravnborg <sam@ravnborg.org>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Paul Mundt <lethal@linux-sh.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: More __meminit annotations.
Date: Mon, 18 Jun 2007 09:45:29 +0200 [thread overview]
Message-ID: <20070618074529.GA21222@uranus.ravnborg.org> (raw)
In-Reply-To: <20070618143943.B108.Y-GOTO@jp.fujitsu.com>
On Mon, Jun 18, 2007 at 02:49:24PM +0900, Yasunori Goto wrote:
> > }
> >
> > -static inline unsigned long zone_absent_pages_in_node(int nid,
> > +static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
> > unsigned long zone_type,
> > unsigned long *zholes_size)
> > {
>
> I thought __meminit is not effective for these static functions,
> because they are inlined function. So, it depends on caller's
> defenition. Is it wrong?
As we do not _know_ if a given function is inline or not it definitely
makes sense to mark them as __meminit.
If the compiler then decides to inline the function we are all clear and
no problems. If the compiler decides not to inline the function we will
properly discard the code after init has completed so again all clear.
And btw. some people (including myself) consider it a bug that gcc inline
a function that is forced to a specific section into a function that belongs
to another section. Now gcc people has another view but that may change.
So again defining a function as __meminit makes sense no matter the
section marker.
For the technical merit whay a function is marker inline in the first place.
It must be assumed this is a hot path where it is benificial to do so.
Sam
--
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:[~2007-06-18 7:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-18 4:52 Paul Mundt
2007-06-18 5:49 ` Yasunori Goto
2007-06-18 5:58 ` Paul Mundt
2007-06-18 6:33 ` Yasunori Goto
2007-06-18 6:57 ` Satyam Sharma
2007-06-18 7:28 ` Satyam Sharma
2007-06-18 7:48 ` Sam Ravnborg
2007-06-18 7:45 ` Sam Ravnborg [this message]
2007-06-18 10:29 ` Satyam Sharma
2007-06-18 10:54 ` Sam Ravnborg
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=20070618074529.GA21222@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=akpm@linux-foundation.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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