mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: vgoyal@in.ibm.com
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@muc.de>,
	Fastboot mailing list <fastboot@lists.osdl.org>,
	Don Zickus <dzickus@redhat.com>
Subject: Re: [PATCH] x86_64: Re-positioning the bss segment
Date: Wed, 16 Aug 2006 00:48:56 -0600	[thread overview]
Message-ID: <m1r6zh5g6f.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060815214952.GB11719@in.ibm.com> (Vivek Goyal's message of "Tue, 15 Aug 2006 17:49:52 -0400")

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

  reply	other threads:[~2006-08-16  6:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-15 21:49 Vivek Goyal
2006-08-16  6:48 ` Eric W. Biederman [this message]
2006-08-16 15:03 ` Andi Kleen
2006-08-16 15:14   ` Vivek Goyal
2006-08-16 18:35   ` Sam Ravnborg

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=m1r6zh5g6f.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@muc.de \
    --cc=dzickus@redhat.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@in.ibm.com \
    /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

all inboxes | Powered by JetHome®