* Hugh Dickins <hugh@veritas.com> wrote:

quoted text
> One point worth noting - is it a worry?  Prior to that smpboot merge, 
> my Xeon booted the two HT siblings on one physical first, then the two 
> siblings on the other physical after - when i386, but alternated them 
> when x86_64.  Since the merge, the x86_64 sequence is unchanged, but 
> the i386 sequence is now like x86_64.  I prefer this consistency, and 
> I prefer the new sequence: booting with maxcpus=2 then uses the 
> independent physicals without HT sharing; but surprises in store?

yep - but right now our view is that such surprises are worth having in 
this case. Basically we now did the more or less "mechanical" 
unification of the two SMP boot codebases, while trying to keep the 
stability track record of both, as much as possible.

The 64-bit SMP boot code (the one which came from arch/x86_64) is 
cleaner, so the plan is to slowly but surely gravitate towards the 
cleaner code - such as with your fix - while not dropping quirks and 
legacies.

It's now possible to do that without impacting the stability (and 
legacy) track record of the 32-bit code too much, because now the code 
is placed next to each other and the differences are plain visible via 
ugly #ifdefs. Whatever change we do is small and revertable.

... but it's still not easy to modify the engine of a race car, in the 
middle of the race - so please be on the lookout and any help is welcome 
;-)

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/