Re: [PATCH] prepare kconfig inline optimization for all architectures

[Adrian Bunk <bunk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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