Messages in this thread | | | Date | Thu, 10 Jun 2004 22:47:00 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.7-rc3-mm1 |
| |
Paul Jackson <pj@sgi.com> 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 footprint.
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 simultaneously. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |