Messages in this thread |  | | | Date | Mon, 17 Nov 2008 22:38:05 +0100 | | From | Ingo Molnar <> | | Subject | Re: skb_release_head_state(): Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28 | |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 17 Nov 2008, Ingo Molnar wrote:
> >
> > this function _really_ hurts from a 16-bit op:
> >
> > ffffffff8048943e: 6503 66 c7 83 a8 00 00 00 movw $0x0,0xa8(%rbx)
> > ffffffff80489445: 0 00 00
> > ffffffff80489447: 174101 5b pop %rbx
>
> I don't think that is it, actually. The 16-bit store just before it
> had a zero count, even though anything that executes the second one
> will always execute the first one too.
yeah - look at the followup bits that identify the likely real source
of that overhead:
>> _But_, the real overhead probably comes from:
>>
>> ffffffff804b7210: 10867 48 8b 54 24 58 mov 0x58(%rsp),%rdx
>>
>> which is the next line, the ttl field:
>>
>> 373 iph->ttl = ip_select_ttl(inet, &rt->u.dst);
>>
>> this shows that we are doing a hard cachemiss on the net-localhost
>> route dst structure cacheline. We do a plain load instruction from
>> it here and get a hefty cachemiss. (because 16 CPUs are banging on
>> that single route)
>>
>> And let make sure we see this in perspective as well: that single
>> cachemiss is _1.0 percent_ of the total tbench cost. (!) We could
>> make the scheduler 10% slower straight away and it would have less
>> of a real-life effect than this single iph->ttl field setting.
|  |