From: ebiederm@xmission.com (Eric W. Biederman)
To: Kurt Garloff <garloff@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux kernel list <linux-kernel@vger.kernel.org>
Subject: Re: SMP on assym. x86
Date: 23 Mar 2001 03:19:28 -0700 [thread overview]
Message-ID: <m1snk423f3.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.10.10103211122500.10337-100000@coffee.psychology.mcmaster.ca> <E14fsET-0001Mg-00@the-village.bc.nu> <20010322130029.A4212@garloff.casa-etp.nl>
In-Reply-To: Kurt Garloff's message of "Thu, 22 Mar 2001 13:00:29 +0100"
Kurt Garloff <garloff@suse.de> writes:
> On Wed, Mar 21, 2001 at 11:41:33PM +0000, Alan Cox wrote:
> > > > handle the situation with 2 different CPUs (AMP = Assymmetric
> > > > multiprocessing ;-) correctly.
> > >
> > > "correctly". Intel doesn't support this (mis)configuration:
> > > especially with different steppings, not to mention models.
>
> I wouldn't call it misconfiguration, just because it's a bit more difficult
> to handle.
> On the iontel side: You should watch out for matching APICs, voltages and
> cache coherency (MESI) protocol. Actually, Deschutes and Coppermine just
> work fine in spite of slightly different voltage.
The spooky thing is if there is that it may work just fine most of the
time but the differences between the CPU's might cause very strange
behavior every once in a great while. Which is a hardware argument, for
why you shouldn't trust such a configuration.
However it is still worth some thought. The hardware argument gets much
weaker when you have something like dual AMD's. The reason is that
with a point to point bus you may actually be able to sanely support
multiple cpu revs and speeds without even any theoretical hardware consequences.
And NUMA machines make this argument even stronger.
However I would suggest that we build some good kernel->kernel apis
for dealing with kernels with a wicked fast interconnect. And then
for NUMA and for the other cases where it really matters we can run multiple
kernels, and the mismatch problems just drop away.
Eric
next prev parent reply other threads:[~2001-03-23 10:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-21 15:55 SMP on assym. x86 Kurt Garloff
2001-03-21 16:32 ` Mark Hahn
2001-03-21 23:41 ` Alan Cox
2001-03-22 12:00 ` Kurt Garloff
2001-03-22 13:48 ` Mark Hahn
2001-03-23 10:19 ` Eric W. Biederman [this message]
2001-03-21 17:16 ` Linus Torvalds
[not found] ` <99anl4oi@penguin.transmeta.com>
2001-03-22 13:20 ` Pavel Machek
2001-03-23 10:18 ` Kurt Garloff
-- strict thread matches above, loose matches on Subject: below --
2001-03-21 19:13 James Bottomley
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=m1snk423f3.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=garloff@suse.de \
--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