Re: [git pull] x86 fixes

From: Linus Torvalds
Date: Mon Sep 08 2008 - 15:30:39 EST

On Mon, 8 Sep 2008, Ingo Molnar wrote:
> but 486 and higher is certainly quite reasonable, and is still being
> tested.
> ... and _in practice_ 99% of all systems that run Linux today understand

cmov, cmpxchg and xadd are the noticeable things.

I think there are realistically three classes:

- _really_ old, to the point of being totally useless for SMP.

This is really just 386 and clones. We _need_ a working WP for a
race-free access_ok(), and we need cmpxchg (and lately xadd).

SMP cannot really realistically work reasonably (ys, there were SMP
machines. No, they don't matter), and you'd have to be insane to care
about this as a vendor even on UP. Probably nobody really cares (ie if
you have hardware that old, you are likely much better off with an
older kernel too)

Smaller pains even on UP: bswap doesn't exist. invlpg doesn't exist.

- old. pre-cmov. i486 and pentium, and some clones.

It's workable, but code generation differences are really big enough
that it's worth having a totally separate architecture option for newer
CPUs where the kernel simply won't work.

And most newer distros probably simply don't care, although there may
be individual cases where this makes sense (embedded places still use
pentium clones etc, and there are probably a fair amount of individuals
that want to still use this)

Other pains: TSC doesn't necessarily exist.

- "modern 32-bit": PPro and better. Can take CMOV, MMX and TSC for

Yes, there are graduations to the above, but reasonably, those three are I
think the "architectural" big versions. The rest should be:

- pure "tuning" options. A Pentium 4 is different from Core 2 in tuning,
and the best code sequences can be very very different, but the binary
should work on both.

- with *dynamic* choices for the differences that are architecturally

Ie the whole choice of syscall/sysenter/int80 is dynamic, not specified
statically at compile time with a config option. So are things like the
different XMM versions etc.

Hmm? Doesn't that sound like a sane model?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at