[RFC] Yet another __init annotation: __initbss

[RFC] Yet another __init annotation: __initbss

[Franck Bui-Huu]

Hi,

Currently, there's no way to make a data part of both the init section
and the bss section. Therefore uninitialized init data consume useless
space in the vmlinux image.

Most of these data can be listed by:

     $ git grep -E "__initdata([^=]*| ?= ?0);" -- *.c

This short patchset is an attempt to make these init data part of the
bss section (done by patch #1) and therefore decreases the size of the
vmlinux image.

For now, only MIPS architecture handles this new section, this is done
by patch #2. It's only a start and should be enough for discussion.

Please consider,

                Franck

[PATCH 1/2] Yet another __initxxx annotations: __initbss/__exitbss

[Franck Bui-Huu]

Currently we can mark an initialized data to belong to the init.data
section, this data being discarded after the boot process and the
memory space used is taken back by the kernel. For _uninitialized_
data, we must use the same mechanism.

The main drawback of this is that these data take space in the kernel
image whereas this space is not really used. It's actually the reason
why we prefer to not initialize a normal data when its initial value
is 0.

This patch creates two new init sections called '.bss.init' and
'.bss.exit'.

These sections are similar to the .{init,exit}.data ones but doesn't
consume any space in the vmlinux image because they're part of the bss
section except that they're freed once the kernel has booted.

To select the BSS attribute for a peculiar section, the name of the
section must start with 'bss.' pattern. This is at least how GCC
3.2/4.1.2 works and it's the reason why the 2 new sections haven't
been called '.{init,exit}.bss'.

To mark a data part of one of these 2 sections, we use the 2 new
annotations: __initbss/__exitbss.

All data marked as part of this section must not be initialized,
of course.

Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
---
 include/linux/init.h |   25 +++++++++++++++++--------
 1 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 5141381..19e04b2 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -43,6 +43,8 @@
 #define __init		__attribute__ ((__section__ (".init.text"))) __cold
 #define __initdata	__attribute__ ((__section__ (".init.data")))
 #define __exitdata	__attribute__ ((__section__(".exit.data")))
+#define __initbss	__attribute__ ((__section__ (".bss.init")))
+#define __exitbss	__attribute__ ((__section__ (".bss.exit")))
 #define __exit_call	__attribute_used__ __attribute__ ((__section__ (".exitcall.exit")))
 
 /* modpost check for section mismatches during the kernel build.
@@ -71,6 +73,7 @@
 #define __FINIT		.previous
 #define __INITDATA	.section	".init.data","aw"
 #define __INITDATA_REFOK .section	".data.init.refok","aw"
+#define __INITBSS	.section	".bss.init","aw",@nobits
 
 #ifndef __ASSEMBLY__
 /*
@@ -260,10 +263,12 @@ void __init parse_early_param(void);
 #define __devexit
 #define __devexitdata
 #else
-#define __devinit __init
-#define __devinitdata __initdata
-#define __devexit __exit
-#define __devexitdata __exitdata
+#define __devinit	__init
+#define __devinitdata	__initdata
+#define __devinitbss	__initbss
+#define __devexit	__exit
+#define __devexitdata	__exitdata
+#define __devexitbss	__exitbss
 #endif
 
 #ifdef CONFIG_HOTPLUG_CPU
@@ -273,9 +278,11 @@ void __init parse_early_param(void);
 #define __cpuexitdata
 #else
 #define __cpuinit	__init
-#define __cpuinitdata __initdata
-#define __cpuexit __exit
+#define __cpuinitdata	__initdata
+#define __cpuinitbss	__initbss
+#define __cpuexit	__exit
 #define __cpuexitdata	__exitdata
+#define __cpuexitbss	__exitbss
 #endif
 
 #if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \
@@ -286,9 +293,11 @@ void __init parse_early_param(void);
 #define __memexitdata
 #else
 #define __meminit	__init
-#define __meminitdata __initdata
-#define __memexit __exit
+#define __meminitdata	__initdata
+#define __meminitbss	__meminitbss
+#define __memexit	__exit
 #define __memexitdata	__exitdata
+#define __memexitbss	__exitbss
 #endif
 
 /* Functions marked as __devexit may be discarded at kernel link time, depending
-- 
1.5.3.5

Re: [PATCH 1/2] Yet another __initxxx annotations: __initbss/__exitbss

[Russell King]

On Sat, Dec 01, 2007 at 10:13:05PM +0100, Franck Bui-Huu wrote:
> To select the BSS attribute for a peculiar section, the name of the
> section must start with 'bss.' pattern. This is at least how GCC
> 3.2/4.1.2 works and it's the reason why the 2 new sections haven't
> been called '.{init,exit}.bss'.
> 
> To mark a data part of one of these 2 sections, we use the 2 new
> annotations: __initbss/__exitbss.
> 
> All data marked as part of this section must not be initialized,
> of course.

Are you sure about this?  The gcc manual for 4.1.1 says:

     Use the `section' attribute with an _initialized_ definition of a
     _global_ variable, as shown in the example.  GCC issues a warning
     and otherwise ignores the `section' attribute in uninitialized
     variable declarations.

which has had that paragraph since at least 3.4.0.  Either the GCC
documentation is wrong or the compiler is misbehaving if what you say
works.  Either way, I'd be nervous about relying on this given that
GCC developers like to change the compiler behaviour.

Suggest getting the GCC developers nailed down to ensure we know what
the intended compiler behaviour is (and getting the docs to reflect that)
before relying on the existing behaviour.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 1/2] Yet another __initxxx annotations: __initbss/__exitbss

[Franck Bui-Huu]

Russell King wrote:
> On Sat, Dec 01, 2007 at 10:13:05PM +0100, Franck Bui-Huu wrote:
>> To select the BSS attribute for a peculiar section, the name of the
>> section must start with 'bss.' pattern. This is at least how GCC
>> 3.2/4.1.2 works and it's the reason why the 2 new sections haven't
>> been called '.{init,exit}.bss'.
>>
>> To mark a data part of one of these 2 sections, we use the 2 new
>> annotations: __initbss/__exitbss.
>>
>> All data marked as part of this section must not be initialized,
>> of course.
> 
> Are you sure about this?  The gcc manual for 4.1.1 says:
> 
>      Use the `section' attribute with an _initialized_ definition of a
>      _global_ variable, as shown in the example.  GCC issues a warning
>      and otherwise ignores the `section' attribute in uninitialized
>      variable declarations.
> 
> which has had that paragraph since at least 3.4.0.  Either the GCC
> documentation is wrong or the compiler is misbehaving if what you say
> works.  Either way, I'd be nervous about relying on this given that
> GCC developers like to change the compiler behaviour.
> 

Thanks for pointing this out.

We already have (incorrectly) uninitialized data which are part of the
init.data section and the section attribute isn't ignored at all, at
least on x86 and mips. On ARM, you could take a look at where
'command_line' array, declared in in arch/arm/kernel/setup.c, is
placed.

So, it seems that we already rely on the compiler behaviour.

> Suggest getting the GCC developers nailed down to ensure we know what
> the intended compiler behaviour is (and getting the docs to reflect that)
> before relying on the existing behaviour.
> 

Yes I agree. Do you have someone in mind to suggest or should I ask to
the GCC mailing list ?

		Franck

[PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections

[Franck Bui-Huu]

Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
---
 arch/mips/kernel/vmlinux.lds.S |   21 ++++++++++++++++-----
 1 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index 5fc2398..8508d3c 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -110,7 +110,7 @@ SECTIONS
 	_edata =  .;			/* End of data section */
 
 	/* will be freed after init */
-	. = ALIGN(_PAGE_SIZE);		/* Init code and data */
+	. = ALIGN(_PAGE_SIZE);		/* Init code, data and bss */
 	__init_begin = .;
 	.init.text : {
 		_sinittext = .;
@@ -158,12 +158,23 @@ SECTIONS
 	}
 #endif
 	PERCPU(_PAGE_SIZE)
-	. = ALIGN(_PAGE_SIZE);
-	__init_end = .;
-	/* freed after init ends here */
 
+	/*
+	 * We keep init/exit bss sections here to have only one
+	 * segment to load. Note that .bss.exit is also discarded
+	 * at runtime for the same reason as above.
+	 */
+	.exit.bss : {
+		*(.bss.exit)
+	}
 	__bss_start = .;	/* BSS */
-	.sbss  : {
+	.init.bss : {
+		*(.bss.init)
+	}
+	. = ALIGN(_PAGE_SIZE);
+	__init_end = .;		/* freed after init ends here */
+
+	.sbss : {
 		*(.sbss)
 		*(.scommon)
 	}
-- 
1.5.3.5

RE: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections

[Luck, Tony]

+	/*
+	 * We keep init/exit bss sections here to have only one
+	 * segment to load. Note that .bss.exit is also discarded
+	 * at runtime for the same reason as above.
+	 */
+	.exit.bss : {
+		*(.bss.exit)
+	}

This change would also require an audit of the bootloader or early
kernel initialization code (whichever handles zeroing of .bss space)
to make sure that it understands that the kernel will now have an
extra block of memory that needs to be cleared.  Perhaps nothing
needs to be done if the code already handled the general case of
loading an ELF binary with some sections that have an in-memory
size bigger than the on-disk size.  But worth looking at in case
the code makes an assumption about what needs to be zeroed.

-Tony

RE: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections

[Luck, Tony]

+	/*
+	 * We keep init/exit bss sections here to have only one
+	 * segment to load. Note that .bss.exit is also discarded
+	 * at runtime for the same reason as above.
+	 */
+	.exit.bss : {
+		*(.bss.exit)
+	}

This change would also require an audit of the bootloader or early
kernel initialization code (whichever handles zeroing of .bss space)
to make sure that it understands that the kernel will now have an
extra block of memory that needs to be cleared.  Perhaps nothing
needs to be done if the code already handled the general case of
loading an ELF binary with some sections that have an in-memory
size bigger than the on-disk size.  But worth looking at in case
the code makes an assumption about what needs to be zeroed.

-Tony

Re: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections

[Franck Bui-Huu]

Luck, Tony wrote:
> +	/*
> +	 * We keep init/exit bss sections here to have only one
> +	 * segment to load. Note that .bss.exit is also discarded
> +	 * at runtime for the same reason as above.
> +	 */
> +	.exit.bss : {
> +		*(.bss.exit)
> +	}
> 
> This change would also require an audit of the bootloader or early
> kernel initialization code (whichever handles zeroing of .bss space)

I think the kernel doesn't rely on the bootloader for clearing bss.

> to make sure that it understands that the kernel will now have an
> extra block of memory that needs to be cleared.  Perhaps nothing
> needs to be done if the code already handled the general case of
> loading an ELF binary with some sections that have an in-memory
> size bigger than the on-disk size.  But worth looking at in case
> the code makes an assumption about what needs to be zeroed.
> 

For MIPS case, there is normally no extra block of memory to
clear. [__bss_start, __bss_stop] range still includes the whole memory
block to clear. So there's no need to modify any other code.

		Franck