On Wed, Mar 21, 2001 at 11:41:33PM +0000, Alan Cox wrote:
> > > handle the situation with 2 different CPUs (AMP =3D Assymmetric
> > > multiprocessing ;-) correctly.
> >=20
> > "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.
> Actually for a lot of cases its quite legal.
It should be always legal to have the same CPU with different speeds. (FSB
must be the same for obvious reasons), e.g.. The TSC part of the patch
addresses this.
> > Alan has, or is working on, a workaround to handle differing=20
> > multipliers by turning off the use of RDTSC. this is the right approac=
h=20
> > to take in the kernel: disable features not shared by both processors,=
=20
> > so correctly-configured machines are not penalized.=20
TSC is supported by both CPUs ... so why not use the nice rdtsc based time
routine.
The penalty:
It is 5 (20 bytes) ints more in the struct cpuinfo_x86, so you have
a kernel with (NR_CPUS*20 - 12) =3D 628 bytes more kernel data ...
Your bootup time may be a fraction of a second longer, as every CPU
calibrates the TSC on its own; OTOH they do it in parallel ...
The timer interrupt does an extra copy of xtime (2 ints) to the to the per
CPU struct. And one extra indirection for accessing the per CPU struct.
Something like 4 CPU cycles per timer interrupt.
gettimeofday() also has this extra indirection; OTOH not accessing global
data saves a cache line flush the next time the structure is written to ...
So this is probably a net cost of zero.
> > and the kernel should LOUDLY WARN ABOUT this stuff on boot.
>=20
> I've been working on reading the multipliers directly from the MSR 0x2A d=
ata,
> Kurt is redoing the timing each run - possibly thats not so clean but its=
=20
> more robust.
>=20
> I rather like Kurt's patch
Thx!=20
If you have some requests to make it suitable for -ac kernels, I'll do my
best.
Regards,
--=20
Kurt Garloff <kurt@garloff.de> [Eindhoven, NL]
Physics: Plasma simulations <K.Garloff@Phys.TUE.NL> [TU Eindhoven, NL]
Linux: SCSI, Security <garloff@suse.de> [SuSE Nuernberg, FRG]
(See mail header or public key servers for PGP2 and GPG public keys.)
--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6uelcxmLh6hyYd04RAnLPAKDSbS0UM+ty0aDs1h370/7jQDF1jwCgtXk/
gwJYx8b0WbqgQYeLRp09M/0=
=FhoH
-----END PGP SIGNATURE-----
--qDbXVdCdHGoSgWSk--
-
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/