Re: [git pull] x86 fixes

From: H. Peter Anvin
Date: Mon Sep 08 2008 - 14:22:47 EST

Linus Torvalds wrote:

On Mon, 8 Sep 2008, H. Peter Anvin wrote:
config X86_GENERIC
- bool "Generic x86 support"
+ bool "Generic x86 support" if EMBEDDED

Ok, so after having realized that this seems to be more about a bug with gcc, I'm really not as convinced any more.

As far as I can tell, there are three issues:

- "-mtune=core/core2/pentium4/.." is buggy in some gas/gcc versions on x86-32, and makes architectural choices.

Any actual _released_ versions? Maybe it's just a current SVN issue?

binutils-, which is the current version on Fedora 9, does this.

Workaround: don't use it. And yes, X86_GENERIC=y will do that, although quite frankly that seems to be dubious in itself. But quite frankly, it's a gcc bug, and we should see it as such.

The better workaround may well be "-Wa,-mtune=generic" as you pointed out.

- We do the CONFIG_P6_NOPL thing ourselves, and we should just stop doing that on 32-bit. There simply isn't a good enough reason to do so. I already posteed the Kconfig.cpu patch to just stop doing it.

As far as I can tell, -Wa,-mtune=generic *should* work. It doesn't look to me as if cc1 will generate the long NOPs. That one we can do unconditionally, of course.

- X86_GENERIC means _other_ things too, like doing a 128-bit cacheline just so that it won't suck horribly on P4's even if it's otherwise tuned for a good microarchitecture.

And they really do seem to be _separate_ issues. Do we really want to tie these things together under X86_GENERIC?

Well, the argument in favour would be that if you want a kernel that can cross between different microarchitectures, then you want the "don't suck horribly on any of them". We can, of course, divide them down further, but is it useful?

The "ideal" way to do any of this would probably to have checkboxes for all the CPUs you want to support and then a drop-down box for the CPU to optimize for. However, the combinatorics of that would be horrible, and it would be very unlikely we would avoid bugs.

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