linux-kernel - Re: next-20081030: voyager compile busted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1225474934.3264.4.camel@localhost.localdomain>
Date:	Fri, 31 Oct 2008 12:42:14 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: next-20081030: voyager compile busted

On Thu, 2008-10-30 at 23:40 +0100, Ingo Molnar wrote: 
> * H. Peter Anvin <hpa@...or.com> wrote:
> 
> > James Bottomley wrote:
> > > 
> > > Yes ... been having IRC conversations about that.  We'd need to use
> > > runtime patching to fix the performance regressions virtualisation has
> > > been causing us first ... but then we could use it for voyager.
> > 
> > I thought we already were, at least to some degree (the call sites 
> > are way too big and way bigger than they need to be, so we end up 
> > with a lot of NOPs.  I proposed a solution to Jeremy at Kernel 
> > Summit, but he basically said "I don't want to maintain that, I 
> > don't care about hardware performance", which is understandable but 
> > highly unfortunate.)
> 
> in practice the function pointer overhead is almost unmeasurable for 
> things like IPIs which are rather expensive to issue. In fact it's 
> probably more expensive on Voyager as it does not utilize the local 
> APIC for SMP messaging (which is pretty much the only 
> performance-sensitive thing here). It uses its own glue logic it 
> appears, which is almost certainly behind the system bus.

Heh ... don't be so sure:  The VIC uses an array of up to 8 standard
8255 IRQ lines, which is slow.  The QIC uses CPI trigger via cache line
interference, which is far faster than APIC bus based systems (but is
fairly similar to the way SAPIC systems work ... almost a decade after
the original QIC system).

> James, how many cycles do typical SMP ops take on Voyager?

To be honest, I'm not too bothered about that.  What bothers me is that
if a normal system performance goes down because of the function pointer
replacement (remember all x86 SMP systems will see an increase in
function pointer usage because of this approach), then it probably
wasn't worth it.

However, the only way to be sure is to try it and get the benchmarks.

James


--
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/