[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: Thu, 4 Oct 2007 16:23:42 +0100 (BST)
Cc: Ralf Baechle <>, Thiemo Seufer <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <>
On Thu, 4 Oct 2007, Franck Bui-Huu wrote:

> It's just a bit sad to see my TLB handler generated at each boot and
> to embed the whole tlbex generator inside the kernel which is quite
> big:
>    $ mipsel-linux-size arch/mips/mm/tlbex.o
>       text    data     bss     dec     hex filename
>      10116    3904    1568   15588    3ce4 arch/mips/mm/tlbex.o
> specially if my cpu doesn't have any bugs.

 Well, most systems are there to work and not to be rebooted repeatedly 
all the time. ;-)  All of tlbex.o is discarded after bootstrap.

> Maybe having, 2 default implementations in tlbex-r3k.S, tlbex-r4k.S
> for good cpus (the ones which needn't any fixups at all) and otherwise
> the tlbex.c is used. And with luck the majority of the cpus are
> good...

 Well, most of the differences are not due to CPU bugs, but different cp0 
hazards.  The MIPS32r2 and MIPS64r2 architecture specs introduce the "ehb" 
and "jr.hb" instructions to sort them out, but most of the processors we 
support predate them.

 The existence of the definitions in <asm/war.h> is there so that 
workarounds for CPU bugs are optimised away at the kernel build time if 
not activated.

 I agree the inclusion both R3k and R4k handlers at the same time even 
though any configuration predetermines which of the two is only going to 
be needed is a bit suboptimal indeed.


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