[Top] [All Lists]

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

To: Franck Bui-Huu <>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: "Maciej W. Rozycki" <>
Date: Mon, 8 Oct 2007 16:39:38 +0100 (BST)
Cc: Ralf Baechle <>, Thiemo Seufer <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
On Mon, 8 Oct 2007, Franck Bui-Huu wrote:

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

 As long as the user is indeed capable of knowing what the exact CPU type 
is.  I have been told replacing R4X00 with a choice like R4000, R4400, 
R4600, R4700 may already be too much of a hassle.

 Frankly I am not entirely confident much choice beyond the ISA level is 
actually a good idea.  We do have it, because lots of bits depend on 
preprocessor conditionals even though they not necessarily should.  There 
are probably some historical reasons too.  But essentially we have about 
eight ISA variations (I - IV and four MIPS Architecture ISAs) and about 
four privileged resource architecture variations (R2000, R6000, R4000, 
R8000); not all combinations making sense and some of the choices actually 
not supported at all.

 CPU variations matter performance-wise, but the use of "-mtune=" is 
irrelevant in this context.

> 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).

 What would be the gain for the kernel from using "-march=4ksd" rather 
than "-march=mips32r2"?

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

 I do not think we happen to handle this scenario -- the more interesting 
configurations that could benefit do not support the cp0.ebase register 
making per-CPU handlers quite a challenge (i.e. the cost would exceed the 

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

 What if you want to run a single kernel image regardless of the CPU 
installed in the system.  Rebuilding the kernel (or having to keep a large 
collection of binaries) just because you want to swap the CPU does not 
seem like a terribly attractive idea.  Some systems come with their CPU(s) 
on a daughtercard (each), you know...


<Prev in Thread] Current Thread [Next in Thread>