From: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Adrian Bunk <bunk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
linux arch <linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH] prepare kconfig inline optimization for all architectures
Date: Sun, 27 Apr 2008 14:14:12 -0400 [thread overview]
Message-ID: <20080427181411.GA31667@infradead.org> (raw)
In-Reply-To: <20080427180957.GA25964-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
On Sun, Apr 27, 2008 at 08:09:57PM +0200, Sam Ravnborg wrote:
> With the config option we pass the inline hint to gcc (if enabled).
> So with the config option we have the possibility to pass a _hint_ to
> gcc about inlining.
>
> Before the config option there were no difference between
> static int alwyas_inline foo() {}
> and
> static int inline foo() {}
>
> With the config option we now have a situation where they actually
> differ as they should do (assuming gcc > 4.x).
As Linus mentioned the hint doesn't make any sense because gcc will
get it wrong anyway. In fact when you look at kernel code it tends
to inline the everything and the kitchensink as long as there's just
one caller and this bloat the stack but doesn't inline where it needs
to. Better don't try to mess with that and do it explicit.
> So you say that it is safe to assume all places where we really need
> always_inline are annotedted such - and we do not need a simple
> config option that the user can uncheck.
I don't say it is that, it certainly isn't on powerpc and probably most
other architectures right now, because only x86 got the fixup so far.
But making it a user-visible option instead of an architecture opt
in/out selection doesn't make any sense.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Adrian Bunk <bunk@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH] prepare kconfig inline optimization for all architectures
Date: Sun, 27 Apr 2008 14:14:12 -0400 [thread overview]
Message-ID: <20080427181411.GA31667@infradead.org> (raw)
Message-ID: <20080427181412.AGk8Ns8-VvHProk797IETiDdcALzRjLt3KzTc4kGnDs@z> (raw)
In-Reply-To: <20080427180957.GA25964@uranus.ravnborg.org>
On Sun, Apr 27, 2008 at 08:09:57PM +0200, Sam Ravnborg wrote:
> With the config option we pass the inline hint to gcc (if enabled).
> So with the config option we have the possibility to pass a _hint_ to
> gcc about inlining.
>
> Before the config option there were no difference between
> static int alwyas_inline foo() {}
> and
> static int inline foo() {}
>
> With the config option we now have a situation where they actually
> differ as they should do (assuming gcc > 4.x).
As Linus mentioned the hint doesn't make any sense because gcc will
get it wrong anyway. In fact when you look at kernel code it tends
to inline the everything and the kitchensink as long as there's just
one caller and this bloat the stack but doesn't inline where it needs
to. Better don't try to mess with that and do it explicit.
> So you say that it is safe to assume all places where we really need
> always_inline are annotedted such - and we do not need a simple
> config option that the user can uncheck.
I don't say it is that, it certainly isn't on powerpc and probably most
other architectures right now, because only x86 got the fixup so far.
But making it a user-visible option instead of an architecture opt
in/out selection doesn't make any sense.
next prev parent reply other threads:[~2008-04-27 18:14 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-27 10:51 [PATCH] prepare kconfig inline optimization for all architectures Sam Ravnborg
2008-04-27 10:51 ` Sam Ravnborg
[not found] ` <20080427105100.GA14795-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2008-04-27 11:31 ` Adrian Bunk
2008-04-27 11:31 ` Adrian Bunk
[not found] ` <20080427113158.GY2252-Aar9JVdAhcRoA3hw4S0G5QR5/fbUUdgG@public.gmane.org>
2008-04-27 11:56 ` Sam Ravnborg
2008-04-27 11:56 ` Sam Ravnborg
[not found] ` <20080427115603.GA23493-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2008-04-27 12:36 ` Ingo Molnar
2008-04-27 12:36 ` Ingo Molnar
[not found] ` <20080427123642.GA28005-X9Un+BFzKDI@public.gmane.org>
2008-04-27 12:49 ` Ingo Molnar
2008-04-27 12:49 ` Ingo Molnar
2008-04-27 17:06 ` Linus Torvalds
2008-04-27 17:06 ` Linus Torvalds
[not found] ` <alpine.LFD.1.10.0804271002360.2896-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-27 17:22 ` Adrian Bunk
2008-04-27 17:22 ` Adrian Bunk
[not found] ` <20080427172235.GA2252-Aar9JVdAhcRoA3hw4S0G5QR5/fbUUdgG@public.gmane.org>
2008-04-27 17:32 ` Linus Torvalds
2008-04-27 17:32 ` Linus Torvalds
[not found] ` <alpine.LFD.1.10.0804271029130.2896-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-27 17:47 ` Adrian Bunk
2008-04-27 17:47 ` Adrian Bunk
[not found] ` <20080427174714.GB2252-Aar9JVdAhcRoA3hw4S0G5QR5/fbUUdgG@public.gmane.org>
2008-04-27 18:00 ` Christoph Hellwig
2008-04-27 18:00 ` Christoph Hellwig
[not found] ` <20080427180007.GB28483-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-04-27 18:09 ` Sam Ravnborg
2008-04-27 18:09 ` Sam Ravnborg
[not found] ` <20080427180957.GA25964-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2008-04-27 18:14 ` Christoph Hellwig [this message]
2008-04-27 18:14 ` Christoph Hellwig
[not found] ` <20080427181411.GA31667-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-04-27 18:24 ` Linus Torvalds
2008-04-27 18:24 ` Linus Torvalds
[not found] ` <alpine.LFD.1.10.0804271118500.2896-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-27 18:32 ` Christoph Hellwig
2008-04-27 18:32 ` Christoph Hellwig
2008-04-27 19:36 ` Ingo Molnar
2008-04-27 19:36 ` Ingo Molnar
[not found] ` <20080427193627.GA32654-X9Un+BFzKDI@public.gmane.org>
2008-04-27 19:49 ` Adrian Bunk
2008-04-27 19:49 ` Adrian Bunk
2008-04-27 23:26 ` Arjan van de Ven
2008-04-27 23:26 ` Arjan van de Ven
[not found] ` <20080427162606.3dd82c0c-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org>
2008-04-27 23:36 ` Linus Torvalds
2008-04-27 23:36 ` Linus Torvalds
[not found] ` <alpine.LFD.1.10.0804271634490.3119-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-27 23:41 ` Ingo Molnar
2008-04-27 23:41 ` Ingo Molnar
2008-04-27 18:31 ` Sam Ravnborg
2008-04-27 18:31 ` Sam Ravnborg
[not found] ` <20080427183131.GA26937-QabhHTsIXMSnlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2008-04-27 18:36 ` Christoph Hellwig
2008-04-27 18:36 ` Christoph Hellwig
2008-04-27 18:11 ` Linus Torvalds
2008-04-27 18:11 ` Linus Torvalds
[not found] ` <alpine.LFD.1.10.0804271053300.2896-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-04-27 18:25 ` Christoph Hellwig
2008-04-27 18:25 ` Christoph Hellwig
[not found] ` <20080427182544.GA23828-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-04-27 18:30 ` Linus Torvalds
2008-04-27 18:30 ` Linus Torvalds
2008-04-27 18:41 ` Adrian Bunk
2008-04-27 18:41 ` Adrian Bunk
[not found] ` <20080427184106.GD2252-Aar9JVdAhcRoA3hw4S0G5QR5/fbUUdgG@public.gmane.org>
2008-04-27 18:57 ` Linus Torvalds
2008-04-27 18:57 ` Linus Torvalds
2008-04-27 20:51 ` Mike Galbraith
2008-04-27 20:51 ` Mike Galbraith
2008-04-27 17:57 ` Christoph Hellwig
2008-04-27 17:57 ` Christoph Hellwig
2008-04-27 17:40 ` Matthew Wilcox
2008-04-27 17:40 ` Matthew Wilcox
[not found] ` <20080427174055.GS14990-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
2008-04-27 17:59 ` Adrian Bunk
2008-04-27 17:59 ` Adrian Bunk
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=20080427181411.GA31667@infradead.org \
--to=hch-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
--cc=bunk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-X9Un+BFzKDI@public.gmane.org \
--cc=sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
/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