[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080427175947.GC2252@cs181133002.pp.htv.fi>
Date: Sun, 27 Apr 2008 20:59:47 +0300
From: Adrian Bunk <bunk@...nel.org>
To: Matthew Wilcox <matthew@....cx>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
linux arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH] prepare kconfig inline optimization for all
architectures
On Sun, Apr 27, 2008 at 11:40:56AM -0600, Matthew Wilcox wrote:
> On Sun, Apr 27, 2008 at 08:22:35PM +0300, Adrian Bunk wrote:
> > I'm looking at it from a different angle, all code in the kernel should
> > follow the following rules [1]:
> > - no functions in .c files should be marked inline
> > - all functions in headers should be static inline
> > - all functions in headers should either be very small or collapse
> > to become very small after inlining
> >
> > I can simply not see any usecase for a non-forced inline in the kernel,
> > and fixing the kernel should give a superset of the space savings of
> > this "inline optimization".
>
> Here's a good counterexample: kernel/mutex.c.
>
> __mutex_lock_common wants to be inlined into __mutex_lock_*_slowpath.
If we really want to force gcc to emit 6 copies of this not so small
function then Ingo's commit in Linus' tree has already broken it on x86.
> and *_slowpath *shouldn't* be inlined into mutex_lock_*.
"noinline" is nothing anyone wants to change.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists