Re: [BUG] x86 kenel won't boot under Virtual PC

[david@lang.hm]

On Mon, 8 Sep 2008, Linus Torvalds wrote:

> On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>>
>> And yes, it should be the default.  The patch I have makes it
>> "default y" as well as change the help text.
>
> It sounds like it shouldn't be a default at all, it should just _always_
> be on, if there really are gcc's that care that much. Most of our
> optimizations have historically really been about _optimizing_, not about
> "it won't work", even if we have had exceptions (but as mentioned, I think
> those exceptions have been way more imporant than NOPL).
>
>> Would it make you happier if this option was forced enabled unless
>> CONFIG_EMBEDDED was on?
>
> Yes, putting it behind EMBEDDED will certainly fix the issue. Anybody who
> actually enables EMBEDDED and does all his choices by hand should no
> longer expect to not have to know _exactly_ what he is doing.
>
> So if it's behind EMBEDDED, and defaults to "on", then I have no problem
> with changing the help text to say "If you do this, we'll statically do
> things that really _require_ you to have a CPU that looks _exactly_ like
> the CPU you claimed".

I always understood the CPU selection to be "this CPU and ones compatible 
with it will work, others won't" unless generic was enabled. the fact that 
only a few CPU's wouldn't work and the rest was optimization is true, but 
the details of what chips would and wouldn't work were never that clear. 
The difference between a kernel compiled for generic and once compiled for 
a specific CPU can be very significant. (I ran into 30% differences back 
in the 2.4 days between generic and Athlon) This is why all the distros 
don't enable the generic cpu option on their kernels nowdays. I'd hate to 
see all the distros enabling embedded just to get this performance boost

David Lang