Re: [PATCH] syscall latency improvement #1

Andrew Morton
2002-01-28T10:38:01Z

Denis Vlasenko wrote:
>
> > <thinks of another>
> >
> > 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:

drivers/block/ll_rw_blk.c | 18 ++-------------
fs/binfmt_elf.c | 4 +--
fs/block_dev.c | 2 -
fs/dcache.c | 8 +++---
fs/inode.c | 6 ++---
fs/locks.c | 8 +++---
fs/namei.c | 14 ++++++------
fs/namespace.c | 42 ++++++++++++++++++++++++++++++++++++
fs/open.c | 4 +--
fs/read_write.c | 2 -
fs/stat.c | 2 -
fs/super.c | 2 -
include/linux/fs_struct.h | 53 +++-------------------------------------------
kernel/exit.c | 10 ++++----
kernel/fork.c | 4 +--
kernel/module.c | 2 -
kernel/sched.c | 6 ++---
kernel/signal.c | 3 --
kernel/sys.c | 2 -
kernel/timer.c | 2 -
lib/rwsem.c | 4 +--
mm/filemap.c | 4 +--
mm/highmem.c | 2 -
mm/memory.c | 2 -
mm/mmap.c | 4 +--
mm/slab.c | 14 ++++++------

And it reduces the kernel image by 11 kbytes. That's not much
RAM, but it's a lot of cache. It's almost all hot-path stuff.

> ...
> * replace those with big_inline
> * #define it to 'inline' or to '' (nothing) and compare kernel sizes
> * make it CONFIG_xxx option if it worth the trouble

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.

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

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

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

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

-