[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.7-rc3-mm1
Paul Jackson <> wrote:
> Do you recall why your i386-uninline-bitops.patch moves i386
> find_next_bit() and find_next_zero_bit() out of line, but not
> find_first_zero_bit() nor find_first_bit()?

They're the two non-leaf functions - they expand other inlines and end up
quite big.

> Perhaps someone else has further insight to the tradeoffs here, such as
> a 'recommended size', above which most routines should be not inlined,
> except in special cases.

Hard call. Lots of hand-waving is involved.

Yes, an aggregate reduction in kernel text size is a good thing, but the
main reason for uninlining things is for performance: reduction of icache

If an inline function is expanded several times in, say, fs/dcache.c then
it's a good candidate for uninlining, because it's probably the case that
all the expanded versions are in icache simultaneously. But if a function
is expanded once in ext2 and once in ext3 then it's less useful to uninline
it, because it is rare that two different filesystem drivers are in use
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.141 / U:0.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site