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

[Adrian Bunk <bunk@fs.tum.de>]

On Sat, Sep 13, 2003 at 06:21:30PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 06:41:46PM +0200, Adrian Bunk wrote:
> 
>  > >  > In 2.6 selecting M486 means that only the 486 is supported.
>  > > 
>  > > What are you basing this on ? This seems bogus to me.
>  > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
>  > 
>  > It currently works.
> 
> Exactly, then your first statement above is bogus.

It was a leftover from a first version where I had a misunderstanding 
regarding the exact effects of X86_L1_CACHE_SHIFT.

If it should continue to work as it currently works the description 
"Generic x86 support" is _very_ misleading.

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

>  > The question is the exact semantics of X86_GENERIC. 
>  > 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

>  > >  > +config CPU_VIAC3_2
>  > >  >  	bool "VIA C3-2 (Nehemiah)"
>  > >  >  	help
>  > >  > -	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
>  > >  > -	  of SSE and tells gcc to treat the CPU as a 686.
>  > >  > -	  Note, this kernel will not boot on older (pre model 9) C3s.
>  > >  > +	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
>  > > 
>  > > You lost an important part of helptext.
>  > With the patch to the Makefile the "enables usage of SSE and tells gcc
>  > to treat the CPU as a 686" is only true if you don't compile support for 
>  > older CPUs.
> 
> 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.

That's the reason why I changed this -march setting (as noted in my 
changelog).

>...
>  > >  > -#ifdef CONFIG_MK7
>  > >  > +#ifndef CONFIG_CPU_CYRIXIII
>  > >  >  
>  > >  >  /*
>  > >  >   *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
>  > > 
>  > > wtf ?
>  > 
>  > It's logical considering the dependencies of X86_USE_3DNOW.
>  > 
>  > But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does 
>  > the same and is less error prone.
> 
> X86_USE_3DNOW would seem more logical to me. I never checked if this
> was a win on C3, but as that also has 3dnow its possibly worth looking into.

Current -test5 (without my patch) has

config X86_USE_3DNOW
        bool
        depends on MCYRIXIII || MK7
        default y

This #ifdef is there to differenciate between the K7 and the generic MMX 
implementation.

>  > >  > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
>  > >  > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
>  > >  > @@ -436,8 +436,12 @@
>  > >  >  	if (!mem_map)
>  > >  >  		BUG();
>  > >  >  #endif
>  > >  > -	
>  > >  > +
>  > >  > +#ifdef CONFIG_CPU_686
>  > >  >  	bad_ppro = ppro_with_ram_bug();
>  > >  > +#else
>  > >  > +	bad_ppro = 0;
>  > >  > +#endif
>  > >  >  
>  > > 
>  > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
>  > 
>  > ppro_with_ram_bug checks for one specific ppro bug.
>  > On a 386 this funtion returns 0.
> 
> I'm not talking about running it on a 386. I'm talking about running
> a kernel _compiled as 386_, on a PPro which has the bug this fixes.
> With your patch, this code does nothing, and the bug doesn't get worked
> around. Currently, it does the right thing. You're saving a half dozen
> or so bytes, and making things like vendor boot kernels (typically
> compiled as 386) not perform a necessary errata workaround.

Well, this is an optional part of my patch. It will be splitted from the 
main part.

> 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?

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

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed