linux-mips
[Top] [All Lists]

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

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 10 Oct 2007 13:17:31 +0100 (BST)
Cc: Franck Bui-Huu <vagabon.xyz@gmail.com>, Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
In-reply-to: <20071010085343.GA31184@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <Pine.LNX.4.64N.0710041616570.10573@blysk.ds.pg.gda.pl> <4705EFE5.7090704@gmail.com> <Pine.LNX.4.64N.0710051312490.17849@blysk.ds.pg.gda.pl> <470A4349.9090301@gmail.com> <Pine.LNX.4.64N.0710081611460.8873@blysk.ds.pg.gda.pl> <20071010085343.GA31184@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 10 Oct 2007, Ralf Baechle wrote:

> >  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.
> 
> Four choices is too much; after all these four marketing names are really
> just 4 variants of two fairly similar processors.  Doable?  Yes.  A useful
> improvment?  I doubt, otoh users of those old machines count every cycle
> by hand still ;-)

 Except from the note on cycle counting ;-) I do agree these days and 
about the only place that cares about the subtleties of the R4k models are 
the TLB handlers which we have now solved with the current approach.

> One of the things I'm trying to achieve is to get rid of all the use of
> CONFIG_CPU_MIPS32_R1 and similar processor symbols in code coming to a
> point where selection of one of those symbols in Kconfig only means to
> optimize a kernel for the selected core without sacrificing compatibility.

 Well, these options should really be used to select the "-march=" option 
only.  We have some places, such as <asm/stackframe.h>, where the 
dependency is tough to eliminate, but that is definitely the right 
direction.

> (But of course the few machines that support processors with multiple ISAs
> spoil that plan a little ..)

 Well, they have cp0.prid and cp0.config* registers at their disposal.

> >  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 
> > benefit).
> 
> It's doable but there is little point.  Ebase is an R2 feature and who
> on earth would mix pre-R2 and R2 cores in a SOC now that R2 is established
> for a few years?

 I have actually thought of one of your pet SGI machine setups -- where 
the CPUs are mixed and are either MIPS III or MIPS IV each.  I do not 
recall you mentioning the exception vector range of RAM being local to the 
CPU cards, so I am assuming the handlers are always shared.

  Maciej

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