This patch makes it an automatic variable instead therefore it
still increases the stack pressure by 512 bytes.
It results in the following size decrease:
tlbex.o~old => tlbex.o
text: 9812 9780 -32 0%
data: 1344 832 -512 -38%
bss: 1568 1568 0 0%
total: 12724 12180 -544 -4%
Signed-off-by: Franck Bui-Huu <fbuihuu@xxxxxxxxx>
---
arch/mips/mm/tlbex.c | 50 +++++++++++++++++++++++++++++---------------------
1 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index ae1bf81..cbcb320 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -735,27 +735,23 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
# define GET_CONTEXT(buf, reg) i_MFC0(buf, reg, C0_CONTEXT)
#endif
-/* The worst case length of the handler is around 18 instructions for
- * R3000-style TLBs and up to 63 instructions for R4000-style TLBs.
- * Maximum space available is 32 instructions for R3000 and 64
- * instructions for R4000.
- *
- * We deliberately chose a buffer size of 128, so we won't scribble
- * over anything important on overflow before we panic.
- */
-static u32 tlb_handler[128] __initdata;
-
/*
* The R3000 TLB handler is simple.
+ *
+ * The worst case length of the handler is around 18 instructions for
+ * R3000-style TLBs and the maximum space available for it is 32
+ * instructions.
+ *
+ * We deliberately chose a buffer size of 64, so we won't scribble
+ * over anything important on overflow before we panic.
*/
static void __init build_r3000_tlb_refill_handler(void)
{
+ u32 tlb_handler[64], *p = tlb_handler;
long pgdc = (long)pgd_current;
- u32 *p;
int i;
memset(tlb_handler, 0, sizeof(tlb_handler));
- p = tlb_handler;
i_mfc0(&p, K0, C0_BADVADDR);
i_lui(&p, K1, rel_hi(pgdc)); /* cp0 delay */
@@ -787,17 +783,19 @@ static void __init build_r3000_tlb_refill_handler(void)
pr_debug("\t.word 0x%08x\n", tlb_handler[i]);
pr_debug("\t.set pop\n");
- memcpy((void *)ebase, tlb_handler, 0x80);
+ memcpy((void *)ebase, tlb_handler, 32);
}
/*
- * The R4000 TLB handler is much more complicated. We have two
- * consecutive handler areas with 32 instructions space each.
- * Since they aren't used at the same time, we can overflow in the
- * other one.To keep things simple, we first assume linear space,
- * then we relocate it to the final handler layout as needed.
+ * The R4000 TLB handler.
+ *
+ * The worst case length of the handler is up to 63 instructions for
+ * R4000-style TLBs and the maximum space available for it is 64
+ * instructions.
+ *
+ * We deliberately chose a buffer size of 128, so we won't scribble
+ * over anything important on overflow before we panic.
*/
-static u32 final_handler[64] __initdata;
/*
* Hazards
@@ -1243,9 +1241,19 @@ static void __init build_update_entries(u32 **p, unsigned int tmp,
#endif
}
+/*
+ * The R4000 TLB handler is much more complicated. We have two
+ * consecutive handler areas with 32 instructions space each.
+ * Since they aren't used at the same time, we can overflow in the
+ * other one.To keep things simple, we first assume linear space,
+ * then we relocate it to the final handler layout as needed.
+ */
+static u32 final_handler[64] __initdata;
+
+
static void __init build_r4000_tlb_refill_handler(void)
{
- u32 *p = tlb_handler;
+ u32 tlb_handler[128], *p = tlb_handler;
struct label labels[128], *l = labels;
struct reloc relocs[128], *r = relocs;
u32 *f;
@@ -1365,7 +1373,7 @@ static void __init build_r4000_tlb_refill_handler(void)
pr_debug("\t.word 0x%08x\n", f[i]);
pr_debug("\t.set pop\n");
- memcpy((void *)ebase, final_handler, 0x100);
+ memcpy((void *)ebase, final_handler, 64);
}
/*
--
1.5.3.3
