[lkml]   [2008]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

    On Tue, 18 Nov 2008, Nick Piggin wrote:

    > On Tuesday 18 November 2008 07:58, David Miller wrote:
    > > From: Linus Torvalds <>
    > > >
    > > > Ok. It could easily be something like a cache footprint issue. And while
    > > > I don't know my sparc cpu's very well, I think the Ultrasparc-IIIi is
    > > > super- scalar but does no out-of-order and speculation, no?
    > >
    > > I does only very simple speculation, but you're description is accurate.
    > Surely it would do branch prediction, but maybe not indirect branch?

    That would be "branch target prediction" (and a BTB - "Branch Target
    Buffer" to hold it), and no, I don't think Sparc does that. You can
    certainly do it for in-order machines too, but I think it's fairly rare.

    It's sufficiently different from the regular "pick up the address from the
    static instruction stream, and also yank the kill-chain on mispredicted
    direction" to be real work to do. Unlike a compare or test instruction,
    it's not at all likely that you can resolve the final address in just a
    single pipeline stage, and without that, it's usually too late to yank the

    (And perhaps equally importantly, indirect branches are relatively rare on
    old-style Unix benchmarks - ie SpecInt/FP - or in databases. So it's not
    something that Sparc would necessarily have spent the effort on.)

    There is obviously one very special indirect jump: "ret". That's the one
    that is common, and that tends to have a special branch target buffer that
    is a pure stack. And for that, there is usually a special branch target
    register that needs to be set up 'x' cycles before the ret in order to
    avoid the stall (then the predition is checking that register against the
    branch target stack, which is somewhat akin to a regular conditional
    branch comparison).

    So I strongly suspect that an indirect (non-ret) branch flushes the
    pipeline on sparc. It is possible that there is a "prepare to jump"
    instruction that prepares the indirect branch stack (kind of a "push
    prediction information"). I suspect Java sees a lot more indirect
    branches than traditional Unix loads, so maybe Sun did do that.


     \ /
      Last update: 2008-11-18 17:03    [W:0.045 / U:84.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site