public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Hugh Dickins <hugh@veritas.com>
Cc: "J.A. Magall??n" <jamagallon@ono.com>,
	Glauber Costa <gcosta@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Problems with -git14
Date: Wed, 30 Apr 2008 20:27:41 +0200	[thread overview]
Message-ID: <20080430182741.GA5783@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0804301516580.30549@blonde.site>


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

> 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

  parent reply	other threads:[~2008-04-30 18:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 23:56 Problems with -git14 J.A. Magallón
2008-04-30 15:17 ` Hugh Dickins
2008-04-29 17:22   ` Arjan van de Ven
2008-04-30 15:54   ` Glauber Costa
2008-05-05  7:13     ` Andrey Panin
2008-05-05  7:49       ` Thomas Gleixner
2008-04-30 18:13   ` Ingo Molnar
2008-04-30 18:27   ` Ingo Molnar [this message]
2008-04-30 19:40   ` J.A. Magallón
2008-05-01 12:04     ` Hugh Dickins
2008-05-01  0:50   ` J.A. Magallón
2008-05-01 12:11     ` Hugh Dickins
2008-05-02  1:41       ` Nick Piggin
2008-05-06 19:13         ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080430182741.GA5783@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=gcosta@redhat.com \
    --cc=hugh@veritas.com \
    --cc=jamagallon@ono.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox