On Mon, 17 Nov 2008, Ingo Molnar wrote: > ffffffff8049e2ae: 0 0f b7 c0 movzwl %ax,%eax > ffffffff8049e2b1: 0 3d ff 05 00 00 cmp $0x5ff,%eax > ffffffff8049e2b6: 468 7f 18 jg ffffffff8049e2d0 <eth_type_trans+0xbb> > ffffffff8049e2b8: 0 48 8b 83 d8 00 00 00 mov 0xd8(%rbx),%rax > ffffffff8049e2bf: 0 b9 00 01 00 00 mov $0x100,%ecx > ffffffff8049e2c4: 0 66 83 38 ff cmpw $0xffffffffffffffff,(%rax) > ffffffff8049e2c8: 0 b8 00 04 00 00 mov $0x400,%eax > ffffffff8049e2cd: 0 0f 45 c8 cmovne %eax,%ecx > ffffffff8049e2d0: 0 5b pop %rbx > ffffffff8049e2d1: 85064 5d pop %rbp > ffffffff8049e2d2: 63776 41 5c pop %r12 > ffffffff8049e2d4: 1 89 c8 mov %ecx,%eax > ffffffff8049e2d6: 474 c3 retq > > small function, big bang - 1.7% of the total overhead. > > 90% of this function's cost is in the closing sequence. My guess would > be that it originates from ffffffff8049e2ae (the branch after that is > not taken), which corresponds to this source code context: I would actually suspect that branch mispredicts may be an issue. If that thing falls out of the branch prediction table (which it could easily do), then a forward branch will be predicted as "not taken". And if it then turns out that the _common_ case is the other way around, the incorrectly predicted destination is often the one that shows up in profiles. Giving gcc likely()/unlikely() hints usually doesn't much help, I'm afraid. It _can_ make a difference, but often not for -Os in particular. Linus -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
