[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200811182044.11055.nickpiggin@yahoo.com.au>
Date: Tue, 18 Nov 2008 20:44:10 +1100
From: Nick Piggin <nickpiggin@...oo.com.au>
To: David Miller <davem@...emloft.net>
Cc: torvalds@...ux-foundation.org, mingo@...e.hu, dada1@...mosbay.com,
rjw@...k.pl, linux-kernel@...r.kernel.org,
kernel-testers@...r.kernel.org, cl@...ux-foundation.org,
efault@....de, a.p.zijlstra@...llo.nl, shemminger@...tta.com
Subject: Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28
On Tuesday 18 November 2008 07:58, David Miller wrote:
> From: Linus Torvalds <torvalds@...ux-foundation.org>
> Date: Mon, 17 Nov 2008 12:30:00 -0800 (PST)
>
> > On Mon, 17 Nov 2008, David Miller wrote:
> > > It's on my workstation which is a much simpler 2 processor
> > > UltraSPARC-IIIi (1.5Ghz) system.
> >
> > 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?
I did wonder why those indirect function calls were added everywhere
in the scheduler...
They didn't show up in the newest generation of x86 CPUs, but simpler
implementations won't handle them as well.
I wouldn't expect that to cause such a big regression on its own, but
it would still be interesting to test changing them to direct calls.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists