From: Franck Bui-Huu <fbuihuu@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Ralf Baechle <ralf@linux-mips.org>,
Thiemo Seufer <ths@networkno.de>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
linux-mips@linux-mips.org
Subject: [PATCH 3/6] tlbex.c: remove tlb_handler[] from init.data section
Date: Tue, 09 Oct 2007 22:36:44 +0200 [thread overview]
Message-ID: <470BE65C.9030407@gmail.com> (raw)
In-Reply-To: <470BE58A.9070709@gmail.com>
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@gmail.com>
---
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
WARNING: multiple messages have this Message-ID (diff)
From: Franck Bui-Huu <fbuihuu@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
Thiemo Seufer <ths@networkno.de>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
linux-mips@linux-mips.org
Subject: [PATCH 3/6] tlbex.c: remove tlb_handler[] from init.data section
Date: Tue, 09 Oct 2007 22:36:44 +0200 [thread overview]
Message-ID: <470BE65C.9030407@gmail.com> (raw)
Message-ID: <20071009203644.VJo06uHT2vZVCRBiWtxneIv75USX3TrTisWTqDrsYNM@z> (raw)
In-Reply-To: <470BE58A.9070709@gmail.com>
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@gmail.com>
---
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
next prev parent reply other threads:[~2007-10-09 20:37 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-02 13:54 [PATCH] mm/pg-r4k.c: Dump the generated code Maciej W. Rozycki
2007-10-02 14:11 ` Thiemo Seufer
2007-10-02 15:49 ` Ralf Baechle
2007-10-02 16:03 ` Thiemo Seufer
2007-10-02 16:08 ` Maciej W. Rozycki
2007-10-03 1:00 ` Ralf Baechle
2007-10-03 7:05 ` Geert Uytterhoeven
2007-10-03 10:32 ` Ralf Baechle
2007-10-03 12:17 ` Franck Bui-Huu
2007-10-03 13:11 ` Thiemo Seufer
2007-10-03 13:51 ` Maciej W. Rozycki
2007-10-03 19:45 ` Franck Bui-Huu
2007-10-03 20:18 ` Thiemo Seufer
2007-10-04 7:33 ` Franck Bui-Huu
2007-10-04 10:30 ` Maciej W. Rozycki
2007-10-04 12:15 ` Ralf Baechle
2007-10-04 15:01 ` Franck Bui-Huu
2007-10-04 15:23 ` Maciej W. Rozycki
2007-10-04 15:30 ` Ralf Baechle
2007-10-04 15:35 ` Maciej W. Rozycki
2007-10-04 15:42 ` Ralf Baechle
2007-10-04 17:34 ` Maciej W. Rozycki
2007-10-08 15:46 ` Maciej W. Rozycki
2007-10-08 16:41 ` Ralf Baechle
2007-10-08 16:45 ` Maciej W. Rozycki
2007-10-08 16:53 ` Ralf Baechle
2007-10-05 8:03 ` Franck Bui-Huu
2007-10-05 9:09 ` Geert Uytterhoeven
2007-10-08 15:02 ` Franck Bui-Huu
2007-10-08 15:21 ` Geert Uytterhoeven
2007-10-08 15:26 ` Ralf Baechle
2007-10-09 20:20 ` Franck Bui-Huu
2007-10-05 12:19 ` Maciej W. Rozycki
2007-10-08 14:48 ` Franck Bui-Huu
2007-10-08 15:24 ` Ralf Baechle
2007-10-08 15:39 ` Maciej W. Rozycki
2007-10-09 20:17 ` Franck Bui-Huu
2007-10-10 11:58 ` Maciej W. Rozycki
2007-10-10 12:08 ` [SPAM?] " Nigel Stephens
2007-10-11 12:01 ` Maciej W. Rozycki
2007-10-13 10:53 ` Richard Sandiford
2007-10-15 13:17 ` Maciej W. Rozycki
2007-10-14 19:37 ` Franck Bui-Huu
2007-10-15 13:26 ` Maciej W. Rozycki
2007-10-14 19:32 ` Franck Bui-Huu
2007-10-14 19:53 ` Thiemo Seufer
2007-10-14 20:29 ` Franck Bui-Huu
2007-10-15 19:35 ` Franck Bui-Huu
2007-10-15 20:11 ` Nigel Stephens
2007-10-16 8:24 ` Franck Bui-Huu
2007-10-16 12:58 ` Nigel Stephens
2007-10-17 7:56 ` Franck Bui-Huu
2007-10-17 12:30 ` Thiemo Seufer
2007-10-17 13:25 ` Nigel Stephens
2007-10-17 13:31 ` Maciej W. Rozycki
2007-11-04 8:21 ` Franck Bui-Huu
2007-11-04 17:47 ` Thiemo Seufer
2007-11-04 20:19 ` Franck Bui-Huu
2007-11-05 11:36 ` Ralf Baechle
2007-11-05 21:34 ` Franck Bui-Huu
2007-11-05 23:30 ` Ralf Baechle
2007-11-06 7:23 ` Franck Bui-Huu
2007-11-05 15:58 ` Nigel Stephens
2007-11-05 20:43 ` Franck Bui-Huu
2007-10-10 8:53 ` Ralf Baechle
2007-10-10 12:17 ` Maciej W. Rozycki
2007-10-05 11:51 ` Ralf Baechle
2007-10-08 14:11 ` Franck Bui-Huu
2007-10-08 14:41 ` Ralf Baechle
2007-10-09 20:33 ` Franck Bui-Huu
2007-10-09 20:34 ` [PATCH 1/6] tlbex.c: Cleanup __init usages Franck Bui-Huu
2007-10-11 16:16 ` Ralf Baechle
2007-10-12 6:36 ` Franck Bui-Huu
2007-10-12 14:43 ` Ralf Baechle
2007-10-09 20:35 ` [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section Franck Bui-Huu
2007-10-09 20:35 ` Franck Bui-Huu
2007-10-10 14:27 ` Ralf Baechle
2007-10-10 16:17 ` Maciej W. Rozycki
2007-10-10 16:42 ` Ralf Baechle
2007-10-10 16:55 ` Geert Uytterhoeven
2007-10-10 17:01 ` Maciej W. Rozycki
2007-10-10 17:09 ` Geert Uytterhoeven
2007-10-10 19:58 ` Franck Bui-Huu
2007-10-10 19:29 ` Franck Bui-Huu
2007-10-09 20:36 ` Franck Bui-Huu [this message]
2007-10-09 20:36 ` [PATCH 3/6] tlbex.c: remove tlb_handler[] from " Franck Bui-Huu
2007-10-09 20:37 ` [PATCH 4/6] tlbex.c: remove final_handler[] " Franck Bui-Huu
2007-10-09 20:37 ` Franck Bui-Huu
2007-10-09 20:38 ` [PATCH 5/6] tlbex.c: cleanup debug code Franck Bui-Huu
2007-10-09 20:38 ` Franck Bui-Huu
2007-10-09 20:39 ` [PATCH 6/6] tlbex.c: cleanup include files Franck Bui-Huu
2007-10-09 20:39 ` Franck Bui-Huu
2007-10-03 13:41 ` [PATCH] mm/pg-r4k.c: Dump the generated code Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=470BE65C.9030407@gmail.com \
--to=fbuihuu@gmail.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=ths@networkno.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox