Re: arch/x86/mm/ioremap unification grew by 10x
* Huang, Ying <[EMAIL PROTECTED]> wrote: > > > And here's most of the cause: > > > > > > 02b8 0124 T early_ioremap > > > 1000 1000 t bm_pte > > > 2000 0004 T early_ioremap_debug > > > > > > static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] > > > __attribute__((aligned(PAGE_SIZE))); > > > > > > Double ouch. First, this isn't in BSS. Second, even though it's > > > initdata, the alignment slop won't get recovered. > > > > 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only > > changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)] > > > > -static __initdata unsigned long bm_pte[1024] > > +static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] > > __attribute__((aligned(PAGE_SIZE))); > > > > I don't think that would have changed anything in this respect. It seems > > to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 > > when it was added (Huang Ying CC'd). > > > > > Don't we have a special section for page-aligned crap so it doesn't > > > waste most of two pages? > > > > We have .bss.page_aligned and it seems appropriate to use it. > > But .bss.page_aligned is not an init section, this will waste some > memory after boot. Do you think that it is more appropriate to add > another section like .init.bss and .init.bss.page_aligned. agreed, and i'd suggest we do so before this information gets forgotten and someone has to re-discover the fix the hard way. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Sun, 2008-02-17 at 19:09 +, Ian Campbell wrote: > On Fri, 2008-02-15 at 17:17 -0600, Matt Mackall wrote: > > On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote: > > > On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: > > > > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: > > > > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In > > > > > 2.6.25-rc1, the unified ioremap.o is 20.8k. > > > > > > > > Just an observation - 17 commits touches said file after > > > > the unification (at least in latest -linus). > > > > > > Correction: those numbers should be halved. So we're going from .9k to > > > 10.4k. > > > > And here's most of the cause: > > > > 02b8 0124 T early_ioremap > > 1000 1000 t bm_pte > > 2000 0004 T early_ioremap_debug > > > > static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] > > __attribute__((aligned(PAGE_SIZE))); > > > > Double ouch. First, this isn't in BSS. Second, even though it's > > initdata, the alignment slop won't get recovered. > > 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only > changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)] > > -static __initdata unsigned long bm_pte[1024] > +static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] > __attribute__((aligned(PAGE_SIZE))); > > I don't think that would have changed anything in this respect. It seems > to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 > when it was added (Huang Ying CC'd). > > > Don't we have a special section for page-aligned crap so it doesn't > > waste most of two pages? > > We have .bss.page_aligned and it seems appropriate to use it. But .bss.page_aligned is not an init section, this will waste some memory after boot. Do you think that it is more appropriate to add another section like .init.bss and .init.bss.page_aligned. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > static __initdata int after_paging_init;
> > -static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
> > - __attribute__((aligned(PAGE_SIZE)));
> > +static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
>
> Replace
> > + __attribute__((__section__(".bss.page_aligned")));
>
> with the shorter form:
> > + __section(.bss.page_aligned)));
i've picked up Ian's patch into x86.git and have done the above change.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Sun, Feb 17, 2008 at 07:09:42PM +, Ian Campbell wrote:
>
> On Fri, 2008-02-15 at 17:17 -0600, Matt Mackall wrote:
> > On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote:
> > > On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
> > > > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
> > > > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
> > > > > 2.6.25-rc1, the unified ioremap.o is 20.8k.
> > > >
> > > > Just an observation - 17 commits touches said file after
> > > > the unification (at least in latest -linus).
> > >
> > > Correction: those numbers should be halved. So we're going from .9k to
> > > 10.4k.
> >
> > And here's most of the cause:
> >
> > 02b8 0124 T early_ioremap
> > 1000 1000 t bm_pte
> > 2000 0004 T early_ioremap_debug
> >
> > static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
> > __attribute__((aligned(PAGE_SIZE)));
> >
> > Double ouch. First, this isn't in BSS. Second, even though it's
> > initdata, the alignment slop won't get recovered.
>
> 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only
> changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)]
>
> -static __initdata unsigned long bm_pte[1024]
> +static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
> __attribute__((aligned(PAGE_SIZE)));
>
> I don't think that would have changed anything in this respect. It seems
> to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
> when it was added (Huang Ying CC'd).
>
> > Don't we have a special section for page-aligned crap so it doesn't
> > waste most of two pages?
>
> We have .bss.page_aligned and it seems appropriate to use it.
>
> Ian.
>
> ---
> From ac954372c1ed7830148bdea1e4283856c05c354f Mon Sep 17 00:00:00 2001
> From: Ian Campbell <[EMAIL PROTECTED]>
> Date: Sun, 17 Feb 2008 19:08:34 +
> Subject: [PATCH] x86: bm_pte can be placed in .bss.page_aligned.
>
> text data bss dec hex filename
> - 3388 8236 4 116282d6c
> ../build-32/arch/x86/mm/ioremap.o
> + 3388 48410075361d70
> ../build-32/arch/x86/mm/ioremap.o
>
> Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> Cc: Matt Mackall <[EMAIL PROTECTED]>
> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
> Cc: Ingo Molnar <[EMAIL PROTECTED]>
> Cc: Huang Ying <[EMAIL PROTECTED]>
> ---
> arch/x86/mm/ioremap.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 69f4981..c62ecbd 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -262,8 +262,8 @@ static int __init early_ioremap_debug_setup(char *str)
> early_param("early_ioremap_debug", early_ioremap_debug_setup);
>
> static __initdata int after_paging_init;
> -static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
> - __attribute__((aligned(PAGE_SIZE)));
> +static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
Replace
> + __attribute__((__section__(".bss.page_aligned")));
with the shorter form:
> + __section(.bss.page_aligned)));
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 17:17 -0600, Matt Mackall wrote:
> On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote:
> > On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
> > > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
> > > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
> > > > 2.6.25-rc1, the unified ioremap.o is 20.8k.
> > >
> > > Just an observation - 17 commits touches said file after
> > > the unification (at least in latest -linus).
> >
> > Correction: those numbers should be halved. So we're going from .9k to
> > 10.4k.
>
> And here's most of the cause:
>
> 02b8 0124 T early_ioremap
> 1000 1000 t bm_pte
> 2000 0004 T early_ioremap_debug
>
> static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
> __attribute__((aligned(PAGE_SIZE)));
>
> Double ouch. First, this isn't in BSS. Second, even though it's
> initdata, the alignment slop won't get recovered.
551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only
changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)]
-static __initdata unsigned long bm_pte[1024]
+static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
__attribute__((aligned(PAGE_SIZE)));
I don't think that would have changed anything in this respect. It seems
to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
when it was added (Huang Ying CC'd).
> Don't we have a special section for page-aligned crap so it doesn't
> waste most of two pages?
We have .bss.page_aligned and it seems appropriate to use it.
Ian.
---
From ac954372c1ed7830148bdea1e4283856c05c354f Mon Sep 17 00:00:00 2001
From: Ian Campbell <[EMAIL PROTECTED]>
Date: Sun, 17 Feb 2008 19:08:34 +
Subject: [PATCH] x86: bm_pte can be placed in .bss.page_aligned.
text data bss dec hex filename
- 3388 8236 4 116282d6c
../build-32/arch/x86/mm/ioremap.o
+ 3388 48410075361d70
../build-32/arch/x86/mm/ioremap.o
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
Cc: Matt Mackall <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Huang Ying <[EMAIL PROTECTED]>
---
arch/x86/mm/ioremap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 69f4981..c62ecbd 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -262,8 +262,8 @@ static int __init early_ioremap_debug_setup(char *str)
early_param("early_ioremap_debug", early_ioremap_debug_setup);
static __initdata int after_paging_init;
-static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
- __attribute__((aligned(PAGE_SIZE)));
+static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
+ __attribute__((__section__(".bss.page_aligned")));
static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
{
--
1.5.4
--
Ian Campbell
In which level of metalanguage are you now speaking?
signature.asc
Description: This is a digitally signed message part
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 17:17 -0600, Matt Mackall wrote:
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote:
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
2.6.25-rc1, the unified ioremap.o is 20.8k.
Just an observation - 17 commits touches said file after
the unification (at least in latest -linus).
Correction: those numbers should be halved. So we're going from .9k to
10.4k.
And here's most of the cause:
02b8 0124 T early_ioremap
1000 1000 t bm_pte
2000 0004 T early_ioremap_debug
static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
__attribute__((aligned(PAGE_SIZE)));
Double ouch. First, this isn't in BSS. Second, even though it's
initdata, the alignment slop won't get recovered.
551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only
changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)]
-static __initdata unsigned long bm_pte[1024]
+static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
__attribute__((aligned(PAGE_SIZE)));
I don't think that would have changed anything in this respect. It seems
to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395
when it was added (Huang Ying CC'd).
Don't we have a special section for page-aligned crap so it doesn't
waste most of two pages?
We have .bss.page_aligned and it seems appropriate to use it.
Ian.
---
From ac954372c1ed7830148bdea1e4283856c05c354f Mon Sep 17 00:00:00 2001
From: Ian Campbell [EMAIL PROTECTED]
Date: Sun, 17 Feb 2008 19:08:34 +
Subject: [PATCH] x86: bm_pte can be placed in .bss.page_aligned.
text data bss dec hex filename
- 3388 8236 4 116282d6c
../build-32/arch/x86/mm/ioremap.o
+ 3388 48410075361d70
../build-32/arch/x86/mm/ioremap.o
Signed-off-by: Ian Campbell [EMAIL PROTECTED]
Cc: Matt Mackall [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Huang Ying [EMAIL PROTECTED]
---
arch/x86/mm/ioremap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 69f4981..c62ecbd 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -262,8 +262,8 @@ static int __init early_ioremap_debug_setup(char *str)
early_param(early_ioremap_debug, early_ioremap_debug_setup);
static __initdata int after_paging_init;
-static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
- __attribute__((aligned(PAGE_SIZE)));
+static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)]
+ __attribute__((__section__(.bss.page_aligned)));
static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
{
--
1.5.4
--
Ian Campbell
In which level of metalanguage are you now speaking?
signature.asc
Description: This is a digitally signed message part
Re: arch/x86/mm/ioremap unification grew by 10x
On Sun, Feb 17, 2008 at 07:09:42PM +, Ian Campbell wrote: On Fri, 2008-02-15 at 17:17 -0600, Matt Mackall wrote: On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote: On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. Just an observation - 17 commits touches said file after the unification (at least in latest -linus). Correction: those numbers should be halved. So we're going from .9k to 10.4k. And here's most of the cause: 02b8 0124 T early_ioremap 1000 1000 t bm_pte 2000 0004 T early_ioremap_debug static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); Double ouch. First, this isn't in BSS. Second, even though it's initdata, the alignment slop won't get recovered. 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)] -static __initdata unsigned long bm_pte[1024] +static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); I don't think that would have changed anything in this respect. It seems to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 when it was added (Huang Ying CC'd). Don't we have a special section for page-aligned crap so it doesn't waste most of two pages? We have .bss.page_aligned and it seems appropriate to use it. Ian. --- From ac954372c1ed7830148bdea1e4283856c05c354f Mon Sep 17 00:00:00 2001 From: Ian Campbell [EMAIL PROTECTED] Date: Sun, 17 Feb 2008 19:08:34 + Subject: [PATCH] x86: bm_pte can be placed in .bss.page_aligned. text data bss dec hex filename - 3388 8236 4 116282d6c ../build-32/arch/x86/mm/ioremap.o + 3388 48410075361d70 ../build-32/arch/x86/mm/ioremap.o Signed-off-by: Ian Campbell [EMAIL PROTECTED] Cc: Matt Mackall [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Huang Ying [EMAIL PROTECTED] --- arch/x86/mm/ioremap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 69f4981..c62ecbd 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -262,8 +262,8 @@ static int __init early_ioremap_debug_setup(char *str) early_param(early_ioremap_debug, early_ioremap_debug_setup); static __initdata int after_paging_init; -static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] - __attribute__((aligned(PAGE_SIZE))); +static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] Replace + __attribute__((__section__(.bss.page_aligned))); with the shorter form: + __section(.bss.page_aligned))); Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
* Sam Ravnborg [EMAIL PROTECTED] wrote: static __initdata int after_paging_init; -static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] - __attribute__((aligned(PAGE_SIZE))); +static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] Replace + __attribute__((__section__(.bss.page_aligned))); with the shorter form: + __section(.bss.page_aligned))); i've picked up Ian's patch into x86.git and have done the above change. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Sun, 2008-02-17 at 19:09 +, Ian Campbell wrote: On Fri, 2008-02-15 at 17:17 -0600, Matt Mackall wrote: On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote: On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. Just an observation - 17 commits touches said file after the unification (at least in latest -linus). Correction: those numbers should be halved. So we're going from .9k to 10.4k. And here's most of the cause: 02b8 0124 T early_ioremap 1000 1000 t bm_pte 2000 0004 T early_ioremap_debug static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); Double ouch. First, this isn't in BSS. Second, even though it's initdata, the alignment slop won't get recovered. 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)] -static __initdata unsigned long bm_pte[1024] +static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); I don't think that would have changed anything in this respect. It seems to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 when it was added (Huang Ying CC'd). Don't we have a special section for page-aligned crap so it doesn't waste most of two pages? We have .bss.page_aligned and it seems appropriate to use it. But .bss.page_aligned is not an init section, this will waste some memory after boot. Do you think that it is more appropriate to add another section like .init.bss and .init.bss.page_aligned. Best Regards, Huang Ying -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
* Huang, Ying [EMAIL PROTECTED] wrote: And here's most of the cause: 02b8 0124 T early_ioremap 1000 1000 t bm_pte 2000 0004 T early_ioremap_debug static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); Double ouch. First, this isn't in BSS. Second, even though it's initdata, the alignment slop won't get recovered. 551889a6e2a24a9c06fd453ea03b57b7746ffdc0 (the reason you CC'd me) only changed this from unsigned long[1024] to pte_t[PAGE_SIZE/sizeof(pte_t)] -static __initdata unsigned long bm_pte[1024] +static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); I don't think that would have changed anything in this respect. It seems to have been that way since 0947b2f31ca1ea1211d3cde2dbd8fcec579ef395 when it was added (Huang Ying CC'd). Don't we have a special section for page-aligned crap so it doesn't waste most of two pages? We have .bss.page_aligned and it seems appropriate to use it. But .bss.page_aligned is not an init section, this will waste some memory after boot. Do you think that it is more appropriate to add another section like .init.bss and .init.bss.page_aligned. agreed, and i'd suggest we do so before this information gets forgotten and someone has to re-discover the fix the hard way. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote: > On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: > > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: > > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In > > > 2.6.25-rc1, the unified ioremap.o is 20.8k. > > > > Just an observation - 17 commits touches said file after > > the unification (at least in latest -linus). > > Correction: those numbers should be halved. So we're going from .9k to > 10.4k. And here's most of the cause: 02b8 0124 T early_ioremap 1000 1000 t bm_pte 2000 0004 T early_ioremap_debug static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); Double ouch. First, this isn't in BSS. Second, even though it's initdata, the alignment slop won't get recovered. Don't we have a special section for page-aligned crap so it doesn't waste most of two pages? -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In > > 2.6.25-rc1, the unified ioremap.o is 20.8k. > > Just an observation - 17 commits touches said file after > the unification (at least in latest -linus). Correction: those numbers should be halved. So we're going from .9k to 10.4k. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In > 2.6.25-rc1, the unified ioremap.o is 20.8k. Just an observation - 17 commits touches said file after the unification (at least in latest -linus). Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arch/x86/mm/ioremap unification grew by 10x
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arch/x86/mm/ioremap unification grew by 10x
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. Just an observation - 17 commits touches said file after the unification (at least in latest -linus). Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. Just an observation - 17 commits touches said file after the unification (at least in latest -linus). Correction: those numbers should be halved. So we're going from .9k to 10.4k. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote: On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. Just an observation - 17 commits touches said file after the unification (at least in latest -linus). Correction: those numbers should be halved. So we're going from .9k to 10.4k. And here's most of the cause: 02b8 0124 T early_ioremap 1000 1000 t bm_pte 2000 0004 T early_ioremap_debug static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); Double ouch. First, this isn't in BSS. Second, even though it's initdata, the alignment slop won't get recovered. Don't we have a special section for page-aligned crap so it doesn't waste most of two pages? -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
