[PATCH] x86_64: Re-positioning the bss segment

[PATCH] x86_64: Re-positioning the bss segment

[Vivek Goyal]

o Currently bss segment is being placed somewhere in the middle (after .data)
  section and after bss lots of init section and data sections are coming.
  Is it intentional?

o One side affect of placing bss in the middle is that objcopy keeps the
  bss in raw binary image (vmlinux.bin) hence unnecessarily increasing
  the size of raw binary image. (In my case ~600K). It also increases
  the size of generated bzImage, though the increase is very small
  (896 bytes), probably a very high compression ratio for stream
  of zeros.

o This patch moves the bss at the end hence reducing the size of
  bzImage by 896 bytes and size of vmlinux.bin by 600K.

o This change benefits in the context of relocatable kernel patches. If
  kernel bss is not part of compressed data (vmlinux.bin) then it does
  not have to be decompressed and this area can be used by the decompressor
  for its execution hence keeping the memory requirements bounded and 
  decompressor code does not stomp over any other data loaded beyond
  kernel image (As might be the case with bootloaders like kexec).

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---

 arch/x86_64/kernel/vmlinux.lds.S |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff -puN arch/x86_64/kernel/vmlinux.lds.S~x86_64-bss-segment-placing-fix arch/x86_64/kernel/vmlinux.lds.S
--- linux-2.6.18-rc3-1M/arch/x86_64/kernel/vmlinux.lds.S~x86_64-bss-segment-placing-fix	2006-08-14 18:46:32.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/x86_64/kernel/vmlinux.lds.S	2006-08-14 20:43:35.000000000 -0400
@@ -61,13 +61,6 @@ SECTIONS
 
   _edata = .;			/* End of data section */
 
-  __bss_start = .;		/* BSS */
-  .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
-	*(.bss.page_aligned)	
-	*(.bss)
-	}
-  __bss_stop = .;
-
   . = ALIGN(PAGE_SIZE);
   . = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
   .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
@@ -222,6 +215,13 @@ SECTIONS
   . = ALIGN(4096);
   __nosave_end = .;
 
+  __bss_start = .;		/* BSS */
+  .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
+	*(.bss.page_aligned)
+	*(.bss)
+	}
+  __bss_stop = .;
+
   _end = . ;
 
   /* Sections to be discarded */
_

Re: [PATCH] x86_64: Re-positioning the bss segment

[Eric W. Biederman]

Vivek Goyal <vgoyal@in.ibm.com> writes:

> o Currently bss segment is being placed somewhere in the middle (after .data)
>   section and after bss lots of init section and data sections are coming.
>   Is it intentional?
>
> o One side affect of placing bss in the middle is that objcopy keeps the
>   bss in raw binary image (vmlinux.bin) hence unnecessarily increasing
>   the size of raw binary image. (In my case ~600K). It also increases
>   the size of generated bzImage, though the increase is very small
>   (896 bytes), probably a very high compression ratio for stream
>   of zeros.
>
> o This patch moves the bss at the end hence reducing the size of
>   bzImage by 896 bytes and size of vmlinux.bin by 600K.
>
> o This change benefits in the context of relocatable kernel patches. If
>   kernel bss is not part of compressed data (vmlinux.bin) then it does
>   not have to be decompressed and this area can be used by the decompressor
>   for its execution hence keeping the memory requirements bounded and 
>   decompressor code does not stomp over any other data loaded beyond
>   kernel image (As might be the case with bootloaders like kexec).

Looks sane here.  I don't know if there are any side effects from placing
the .bss after the .init sections that we discard at after boot.

Unless this has undesirable side effects this should have us doing the
expected thing, with the .bss section which is less likely to confuse people
in general.

> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Acked-by: Eric Biederman <ebiederm@xmission.com>

Eric

Re: [PATCH] x86_64: Re-positioning the bss segment

[Andi Kleen]

On Tue, 15 Aug 2006 17:49:52 -0400
Vivek Goyal <vgoyal@in.ibm.com> wrote:

> 
> o Currently bss segment is being placed somewhere in the middle (after .data)
>   section and after bss lots of init section and data sections are coming.
>   Is it intentional?

Not that I know of.

> 
> o One side affect of placing bss in the middle is that objcopy keeps the
>   bss in raw binary image (vmlinux.bin) hence unnecessarily increasing
>   the size of raw binary image. (In my case ~600K). It also increases
>   the size of generated bzImage, though the increase is very small
>   (896 bytes), probably a very high compression ratio for stream
>   of zeros.
> 
> o This patch moves the bss at the end hence reducing the size of
>   bzImage by 896 bytes and size of vmlinux.bin by 600K.
> 
> o This change benefits in the context of relocatable kernel patches. If
>   kernel bss is not part of compressed data (vmlinux.bin) then it does
>   not have to be decompressed and this area can be used by the decompressor
>   for its execution hence keeping the memory requirements bounded and 
>   decompressor code does not stomp over any other data loaded beyond
>   kernel image (As might be the case with bootloaders like kexec).

Merged thanks. 

Does i386 need a similar change?

-Andi

 

Re: [PATCH] x86_64: Re-positioning the bss segment

[Vivek Goyal]

On Wed, Aug 16, 2006 at 05:03:14PM +0200, Andi Kleen wrote:
> On Tue, 15 Aug 2006 17:49:52 -0400
> Vivek Goyal <vgoyal@in.ibm.com> wrote:
> 
> > 
> > o Currently bss segment is being placed somewhere in the middle (after .data)
> >   section and after bss lots of init section and data sections are coming.
> >   Is it intentional?
> 
> Not that I know of.
> 
> > 
> > o One side affect of placing bss in the middle is that objcopy keeps the
> >   bss in raw binary image (vmlinux.bin) hence unnecessarily increasing
> >   the size of raw binary image. (In my case ~600K). It also increases
> >   the size of generated bzImage, though the increase is very small
> >   (896 bytes), probably a very high compression ratio for stream
> >   of zeros.
> > 
> > o This patch moves the bss at the end hence reducing the size of
> >   bzImage by 896 bytes and size of vmlinux.bin by 600K.
> > 
> > o This change benefits in the context of relocatable kernel patches. If
> >   kernel bss is not part of compressed data (vmlinux.bin) then it does
> >   not have to be decompressed and this area can be used by the decompressor
> >   for its execution hence keeping the memory requirements bounded and 
> >   decompressor code does not stomp over any other data loaded beyond
> >   kernel image (As might be the case with bootloaders like kexec).
> 
> Merged thanks. 
> 
> Does i386 need a similar change?

Nope. i386 already has bss at the end.

Thanks
Vivek

Re: [PATCH] x86_64: Re-positioning the bss segment

[Sam Ravnborg]

On Wed, Aug 16, 2006 at 05:03:14PM +0200, Andi Kleen wrote:
 > 
> > o This patch moves the bss at the end hence reducing the size of
> >   bzImage by 896 bytes and size of vmlinux.bin by 600K.
> > 
> > o This change benefits in the context of relocatable kernel patches. If
> >   kernel bss is not part of compressed data (vmlinux.bin) then it does
> >   not have to be decompressed and this area can be used by the decompressor
> >   for its execution hence keeping the memory requirements bounded and 
> >   decompressor code does not stomp over any other data loaded beyond
> >   kernel image (As might be the case with bootloaders like kexec).
> 
> Merged thanks. 
> 
> Does i386 need a similar change?
If it does then I suggest moving the BSS definition to
include/asm-generic/vmlinux.lds.h

	Sam