mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <ak@suse.de>,
	Ian Campbell <ijc@hellion.org.uk>, Matt Mackall <mpm@selenic.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86 : add init BSS sections
Date: Thu, 21 Feb 2008 10:52:37 +0100	[thread overview]
Message-ID: <20080221095237.GA26714@uranus.ravnborg.org> (raw)
In-Reply-To: <1203581721.4707.19.camel@caritas-dev.intel.com>

Hi Huang.

A few comments..

> Init BSS sections are added for uninitialized init DATA sections to
> reduce kernel image size.

- If this is relevant for more than just x86 then the definition
  of the section should be in include/asm-generic/vmlinux.lds.h

- Please add a comment along the definitions in the .lds file
  explaning the use of the section.
- Same goes for init.h

- Is this concept restricted to __init or is it
  relevant for __devinit etc (I hope we can avoid that)

- Can we do any kind of build time check to catch
  accidental misuse?

	Sam



> 
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> 
> ---
>  arch/x86/kernel/head64.c         |    2 ++
>  arch/x86/kernel/head_32.S        |    5 +++++
>  arch/x86/kernel/vmlinux_32.lds.S |    9 +++++++--
>  arch/x86/kernel/vmlinux_64.lds.S |   24 ++++++++++++++----------
>  include/asm-generic/sections.h   |    1 +
>  include/linux/init.h             |    1 +
>  6 files changed, 30 insertions(+), 12 deletions(-)
> 
> --- a/arch/x86/kernel/vmlinux_32.lds.S
> +++ b/arch/x86/kernel/vmlinux_32.lds.S
> @@ -189,10 +189,15 @@ SECTIONS
>  	__per_cpu_end = .;
>    }
>    . = ALIGN(PAGE_SIZE);
Do we really need to aling this to PAGE_SIZE - I
assume we free everything in one go - or?

> -  /* freed after init ends here */
>  
>    .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
> -	__init_end = .;
> +	__init_bss_start = .;
> +	*(.bss.init.page_aligned)
I do not see this section used anywhere. At least init.h does not
define it.


> +	*(.bss.init)
> +	. = ALIGN(4);
> +	__init_bss_stop = .;
> +	. = ALIGN(PAGE_SIZE);

Why do we have these two ALIGN() following each other?
The latter should be enough.

> +	__init_end = .;			/* freed after init ends here */
>  	__bss_start = .;		/* BSS */
>  	*(.bss.page_aligned)
>  	*(.bss)
> --- a/arch/x86/kernel/vmlinux_64.lds.S
> +++ b/arch/x86/kernel/vmlinux_64.lds.S
> @@ -150,6 +150,12 @@ SECTIONS
>    . = ALIGN(PAGE_SIZE);
>    __smp_alt_end = .;
>  
> +  . = ALIGN(PAGE_SIZE);
> +  __nosave_begin = .;
> +  .data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) { *(.data.nosave) }
> +  . = ALIGN(PAGE_SIZE);
> +  __nosave_end = .;
> +
This change looks unrelated - it is not in the changelog.
Or is it just diff that fools me?

>    . = ALIGN(PAGE_SIZE);		/* Init code and data */
>    __init_begin = .;
>    .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
> @@ -219,17 +225,15 @@ SECTIONS
>  
>    PERCPU(PAGE_SIZE)
>  
> -  . = ALIGN(PAGE_SIZE);
> -  __init_end = .;
> -
> -  . = ALIGN(PAGE_SIZE);
> -  __nosave_begin = .;
> -  .data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) { *(.data.nosave) }
> -  . = ALIGN(PAGE_SIZE);
> -  __nosave_end = .;
> -
> -  __bss_start = .;		/* BSS */
> +  . = ALIGN(PAGE_SIZE);		/* BSS */
>    .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
> +	__init_bss_start = .;
> +	*(.bss.init.page_aligned)
> +	*(.bss.init)
> +	__init_bss_stop = .;
> +	. = ALIGN(PAGE_SIZE);
> +	__init_end = .;
> +	__bss_start = .;
>  	*(.bss.page_aligned)
>  	*(.bss)
>  	}
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -105,6 +105,11 @@ ENTRY(startup_32)
>   */
>  	cld
>  	xorl %eax,%eax
> +	movl $pa(__init_bss_start),%edi
> +	movl $pa(__init_bss_stop), %ecx
> +	subl %edi,%ecx
> +	shrl $2,%ecx
> +	rep ; stosl
>  	movl $pa(__bss_start),%edi
>  	movl $pa(__bss_stop),%ecx
>  	subl %edi,%ecx

How about introducing head32.c and do this in a similar
way that 64 bit does?
Then we could later move more stuff to said file.


	Sam

      reply	other threads:[~2008-02-21  9:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-21  8:15 Huang, Ying
2008-02-21  9:52 ` Sam Ravnborg [this message]

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=20080221095237.GA26714@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=ak@suse.de \
    --cc=hpa@zytor.com \
    --cc=ijc@hellion.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpm@selenic.com \
    --cc=tglx@linutronix.de \
    --cc=ying.huang@intel.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®