Re: [PATCH] mm/pg-r4k.c: Dump the generated code

[Ralf Baechle <ralf@linux-mips.org>]

On Mon, Oct 08, 2007 at 04:48:41PM +0200, Franck Bui-Huu wrote:

> Maciej W. Rozycki wrote:
> > The exact CPU type is not known at the moment.  For example CPU_R4X00 and 
> > CPU_MIPS32_R1 cover whole ranges that have subtle differences.  It may be 
> > possible to provide all the variations as a selection to the user, but it 
> > may be unfeasible -- I don't know.  Compare what we have in 
> > arch/mips/Kconfig with <asm/cpu.h>.
> > 
> 
> OK, I see.
> 
> Well, having all cpu variations in Kconfig should be technically
> possible. The user needs to know what exact cpu is running on which
> doesn't sound impossible and we could add some sanity checkings to
> ensure he doesn't messed up its configuration.

I don't consider this much of a problem.  The machines which either
have one or multiple of the R4000 family or a mix of of R10000 family
processors simply shouldn't hardwire the CPU types.  The R4000 machines
can afford the few bytes of kernel executable and the R10000 machines
often come with ridiculous amounts of memory anyway.

> BTW, we could pass more cpu compiler options for optimization this
> way. For example, when using a '4ksd' cpu, we currently can't pass
> '-march=4ksd' to gcc since the cpu type used for it is 'mips32r2'. And
> I guess it's true for all cpu types which cover a range of slightly
> different processors (r4x00 comes in mind).
> 
> OTOH, I don't know if it can work on SMP: if the system needs 2
> different implementations of the handler (I don't know if it can
> happen though), we must be able to select 2 different cpu types in
> Kconfig...

The currently only multiprocessor systems which allow mixing of different
processors are the SGI machines and there we have the restriction to
at least the same family of processors, see above.  One which I sooner
or later expect to see is CMP systems with different clock rates per
processor.

> Do you see any other points that we should consider before trying to
> use static handlers ? Some other cpu features influencing the tlb
> handler generations and that can be found only at runtime ?

  Ralf