On Sun, 16 Aug 2009, Ingo Molnar wrote: > > What's the current situation on s390, precisely which of the 28 lock > functions are a win to be inlined and which ones are a loss? Do you > have a list/table perhaps? Let's look at x86 instead. The one I can _guarantee_ is worth inlining is "spin_unlock()", since it just generates a single "incb %m" or whatever. No loops, no conditionals, no nuthing. It's not even a locked instruction. Right now we literally generate this function for it: 0xffffffff81420d74 <_spin_unlock+0>: push %rbp 0xffffffff81420d75 <_spin_unlock+1>: mov %rsp,%rbp 0xffffffff81420d78 <_spin_unlock+4>: incb (%rdi) 0xffffffff81420d7a <_spin_unlock+6>: leaveq 0xffffffff81420d7b <_spin_unlock+7>: retq iow, the actual "bulk" of that function is a single two-byte instruction. And for that we generate a whole 5-byte "call" instruction, along with all the costs of fixed register scheduling and stupid spilling etc. read_unlock and write_unlock are similar, and are lock incl (%rdi) // 3 bytes and lock addl $0x1000000,(%rdi) // 7 bytes respectively. At 7 bytes, write_unlock() is still likely to be smaller inlined (because you avoid the register games). Other cases on x86 that would be smaller in-lined: - _spin_unlock_irq: 3 bytes incb (%rdi) sti - _spin_unlock_irqrestore: 4 bytes incb (%rdi) push %rsi popfq - _read_unlock_irq/_read_unlock_irqrestore (4 and 5 bytes respectively): lock incl (%rdi) sti / push+popfq but not, for example, any of the locking functions, nor any of the "_bh" versions (because local_bh_enable ends up pretty complicated, unlike local_bh_disable). Nor even perhaps - _write_unlock_irqrestore: (9 bytes) lock addl $0x1000000,(%rdi) push %rsi popfq which is starting to get to the point where a call _may_ be smaller (largely due to that big constant). And '_spin_lock()' is already too big to inline: mov $0x100,%eax lock xadd %ax,(%rdi) cmp %ah,%al je 2f pause mov (%rdi),%al je 1b which is 20 bytes or so, and that's the simplest of the locking cases. So you really do have a mix of "want to inline" and "do not want to inline". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
