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
