Re: RFC: [2.6 patch] better i386 CPU selection

Dave Jones
2003-09-13T18:37:37Z

On Sat, Sep 13, 2003 at 08:22:12PM +0200, Adrian Bunk wrote:

> What does a user think on which machines a kernel will run after he
> enabled the following options?
> - "Athlon/Duron/K7"
> - "Generic x86 support"

Currently, as you can only choose one of them, it should be obvious.
With your 'you can choose n number of options' patch, it becomes
confusing why there is a generic option at all.

> > > If you read the description of X86_GENERIC it implicitely says a kernel
> > > for a 386 isn't generic.
> > Apart from using incorrect cache line alignments on P4, an i386 kernel
> > is no more, no less generic than one compiled with X86_GENERIC
> plus X86_INTEL_USERCOPY

Sure, but that still doesn't prevent it being used on any system as
a generic kernel.

> > Incidentally, looking closer you broke this option.
> >
> > +ifdef CONFIG_CPU_VIAC3_2
> > + cpuflags-y := $(call check_gcc,-march=c3,-march=i686)
> > +endif
> >
> > Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
> > prefetches. One thing that just occured to me, it may be possible
> >...
>
> Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.

the 3.3.2 and 3.4 branches have it.

> > And "You can select 486/586/686 too" is not an answer. These kernels
> > need to be small, and errata workarounds should NEVER be compiled out
> > for exactly this reason.
> >...
> Why is a kernel compiled with support for all CPUs necessarily much
> bigger than a current M386 kernel?

Adding in stuff like cpu specific memory copy routines for example.
There have been several cases where vendors haven't been able to squeeze a
boot kernel onto a CD by 40 or so bytes in the past, leading to a last
minute scavenge to try and reclaim that space. Every little helps.

> OTOH, why waste space on a 486 for 3DNow! support?

I'm arguing for errata workarounds, not extended support.

Dave

--
Dave Jones http://www.codemonkey.org.uk