Re: [PATCH] syscall latency improvement #1

[Denis Vlasenko]

On 28 January 2002 08:30, Andrew Morton wrote:
> > >       s/inline//g
> >
> > I like this.
>
> Well, it's a fairly small optimisation, but it's easy.
>
> I did a patch a while back: 
> http://www.zip.com.au/~akpm/linux/2.4/2.4.17-pre1/inline.patch This is
> purely against core kernel files:

[snip]

How did you find big inlines? Care to share hunter script with me (+ lkml)?

> The first patch should be against Documentation/CodingStyle.
> What are we trying to achieve here?  What are the guidelines
> for when-to and when-to-not?  I'd say:
>
> - If a function has a single call site and is static then it
>   is always correct to inline.

And what if later you (or someone else!) add another call? You may forget to 
remove inline. It adds maintenance trouble while not buying much of speed:
if func is big, inline gains are small, if it's small, it should be inlined 
regardless of number of call sites.

> - If a function is very small (20-30 bytes) then inlining
>   is correct even if it has many call sites.

Small in asm code, _not_ in C. Sometimes seemingly small C explodes into 
horrendous asm.

> - If a function is less-small, and has only one or two
>   *commonly called* call sites, then inlining is OK.

How much less small? We can have both:

inline int f_inlined() { ... }
int f() { return f_inline(); }
...
f_inlined(); /* we need speed here */
f(); /* we save space here */

> - If a function is a leaf function, then it is more inlinable
>   than a function which makes another function call.

100%. Especially when some "cute small functions" called inside happen to be 
inlined too (or are macros).

> fs/inode.c:__sync_one() violates all the above quite
> outrageously :)

Homehow I feel there are more :-)
--
vda