Messages in this thread | | | Date | Wed, 5 Jul 2006 13:18:24 -0700 | From | Andrew Morton <> | Subject | Re: [patch] uninline init_waitqueue_*() functions |
| |
Ingo Molnar <mingo@elte.hu> wrote: > > > > i also tried a config with the best size settings (disabling > > > FRAME_POINTER, enabling CC_OPTIMIZE_FOR_SIZE), and this gives: > > > > > > text data bss dec filename > > > 20777768 6076042 3081864 29935674 vmlinux.x32.size.before > > > 20748140 6076178 3081864 29906182 vmlinux.x32.size.after > > > > > > or a 34.8 bytes win per callsite (29K total). > > > > > > > With gcc-4.1.0 on i686, uninlining those three functions as per the > > below patch _increases_ the allnoconfig vmlinux's .text from 833456 > > bytes to 833728. > > that's just the effect of CONFIG_REGPARM and CONFIG_CC_OPTIMIZE_FOR_SIZE > not being set in an allnoconfig. Once i set them the text size evens > out: > > 431348 60666 27276 519290 7ec7a vmlinux.x32.mini.before > 431359 60666 27276 519301 7ec85 vmlinux.x32.mini.after > > compiling without CONFIG_REGPARM on i686 (if you care about text size) > makes little sense. It penalizes function calls artificially.
OK, but what happened to the 35-bytes-per-callsite saving?
Sorry to keep going on about this, but your numbers seem just too big to me, and the above confirms that, and I don't know what's happening.
It doesn't seem right that uninlining something like this:
static inline void init_waitqueue_func_entry(wait_queue_t *q, wait_queue_func_t func) { q->flags = 0; q->private = NULL; q->func = func; }
is going to gain us much code size benefit at all. Let alone runtime/codegen benefit. - 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/
| |