Date:	Thu, 30 Oct 2008 16:21:48 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	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>,
	"H. Peter Anvin" <hpa@...or.com>, Yinghai Lu <yinghai@...nel.org>
Subject: Re: next-20081030: voyager compile busted

On Thu, 2008-10-30 at 22:07 +0100, Ingo Molnar wrote:
> * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > > Would you be interested in helping us out with such a project? It 
> > > would be a nice cleanup for sure.
> > 
> > Sure, I'd be interested in looking into that.
> > 
> > However, it won't help the problems since they're mostly compile 
> > breakages caused by tampering with the HAL API for x86 and not 
> > seeing that this affects various subarches. [...]
> 
> it would fix that problem largely because we'd no longer have such 
> 'HAL API' - we'd have runtime differences and function pointers.

Before you advocate this, think what it would entail.  Voyager replaces
(and has to replace because its not apic based) the entirety of smp.c
and smpboot.c ... they'd all have to be abstracted through function
pointers.

Originally I wanted to do this ... after all, it's the way solaris does
its SMP hal replacement as well, but a lot of argument on the mailing
lists back in 1998 convinced me that we didn't want to pay the pipeline
disruption penalty of a function pointer for every SMP operation.  I
know CPUs have become way faster over that decade, but I believe (feel
free to correct) that the pipeline disruption penalty of function
pointers has actually become worse, not better.

The subarchitectures, with their direct function replacement (and
consequent having to accept a particular one to compile with) was the
final compromise.

I really think you don't want voyager slowing down mainline SMP by even
a few percentage points?

> > [...]  Moving voyager to a quirk wouldn't fix that problem.
> 
> btw., Voyager would not be a "quirk" (putting it that way looks a bit 
> derogatory perhaps) - instead it would be a regular x86 platform, with 
> a couple of quirk handlers to handle Voyager specialities.
> 
> Look at how CONFIG_X86_VISWS works today for example: that option only 
> activates the quirk handlers - and a VISWS bzImage will boot fine on a 
> regular PC. This is a far more powerful way of handling x86 hardware 
> deviations than a full build-time thing. It makes it also far easier 
> to test - while we cannot test the _quirks_, we can easily test the 
> build and still boot it on regular PCs. (which makes it far more 
> likely for people to enable this option)
> 
> This principle was followed for all the x86 subarchitectures we've 
> converted already: visws and numaq is done, rdc3210 is basically there 
> already. (waiting for generic gpio bits to complete that fully - but 
> rdc otherwise has no differences from the generic arch code)
> 
> Voyager is certainly one of the most complex subarch cases, hence was 
> it left last :-)

Yes ... but the problem is that all the rest (even numa and visws) use
smp.c and smpboot.c.  That makes them essentially x86 apic systems with
a few quirks (which is ideal for a quirk based system).  Voyager
isn't ... it replaces the entire SMP HAL.

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/

Powered by blists - more mailing lists