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

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

On Thu, Oct 04, 2007 at 05:01:32PM +0200, Franck Bui-Huu wrote:

(Hitting the send key now so nobody notices I wrote this email at 3am ;-)

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

So I did a few experiments.  This is the size of tlbex for a malta_defconfig
build with gcc 4.2.1:

   text    data     bss     dec     hex filename
  10468    3904    1568   15940    3e44 arch/mips/mm/tlbex.o

After replacing current_cpu_data.cputype with a new macro current_cpu_type
that expands to the constant CPU type value, I picked CPU_4KC:

   text    data     bss     dec     hex filename
   6088    3904    1568   11560    2d28 arch/mips/mm/tlbex.o

And after also changing r45k_bvahwbug, r4k_250MHZhwbug, bcm1250_m3_war,
r10000_llsc_war and m4kc_tlbp_war into inline functions:

   text    data     bss     dec     hex filename
   5608    3904    1568   11080    2b48 arch/mips/mm/tlbex.o

So I applied the inlining change to the queue tree and came up with a
generalized version of the current_cpu_type.   This are the sizes I get
for a malta kernel without and with hardwiring the CPU type to 4Kc:

     text    data     bss     dec     hex filename
  3273876  142324  140944 3557144  364718 vmlinux
  3267048  142324  140944 3550316  362c6c vmlinux

6828 bytes isn't totally amazing but since the optimization is reasonable
clean I'm going to queue this one also.

  Ralf