lkml.org 
[lkml]   [2009]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v7][RFC]: mutex: implement adaptive spinning

> - Headers could probably go back to 'extern inline' again. At not small
> expense - we just finished moving to 'static inline'. We'd need to
> guarantee a library instantiation for every header include file - this
> is an additional mechanism with additional introduction complexities
> and an ongoing maintenance cost.

I thought the "static inline" in headers should be more of a "always
inline". As Andrew Morton keeps yelling at me to use static inline instead
of macros ;-)

I do not see the point in the functions in the headers needing to have
their "inlines" removed.

>
> - 'static inline' functions in .c files that are not used cause no build
> warnings - while if we change them to 'static', we get a 'defined but
> not used' warning. Hundreds of new warnings in the allyesconfig builds.

Perhaps that's a good thing to see what functions are unused in the
source.

>
> I know that because i just have removed all variants of 'inline' from all
> .c files of the kernel, it's a 3.5MB patch:
>
> 3263 files changed, 12409 insertions(+), 12409 deletions(-)
>
> x86 defconfig comparisons:
>
> text filename
> 6875817 vmlinux.always-inline ( 0.000% )
> 6838290 vmlinux.always-inline+remove-c-inlines ( -0.548% )
> 6794474 vmlinux.optimize-inlining ( -1.197% )
>
> So the kernel's size improved by half a percent. Should i submit it?

Are there cases that are "must inline" in that patch? Also, what is the
difference if you do vmlinux.optimize-remove-c-inlines? Is there a
difference there?
-- Steve



\
 
 \ /
  Last update: 2009-01-10 02:21    [from the cache]
©2003-2011 Jasper Spaans