Messages in this thread | | | Date | Sun, 27 Apr 2008 20:59:47 +0300 | From | Adrian Bunk <> | 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
| |