lkml.org 
[lkml]   [2008]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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.


    \
     
     \ /
      Last update: 2008-11-17 22:41    [W:0.031 / U:64.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site