[PATCH] ARM: put memblock stuff into init sections

[PATCH] ARM: put memblock stuff into init sections

[Uwe Kleine-König]

memblock is only used during early boot for ARM, so the function and
data can safely go into the init sections.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/include/asm/memblock.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/memblock.h b/arch/arm/include/asm/memblock.h
index b8da2e4..6e937f7 100644
--- a/arch/arm/include/asm/memblock.h
+++ b/arch/arm/include/asm/memblock.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_ARM_MEMBLOCK_H
 #define _ASM_ARM_MEMBLOCK_H
 
+#define ARCH_DISCARD_MEMBLOCK
+
 struct meminfo;
 struct machine_desc;
 
-- 
1.7.7.1

[PATCH] ARM: put memblock stuff into init sections

[Russell King - ARM Linux]

On Thu, Dec 01, 2011 at 11:24:50PM +0100, Uwe Kleine-K?nig wrote:
> memblock is only used during early boot for ARM, so the function and
> data can safely go into the init sections.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

NAK, for several reasons.  Tejun has a patch whose description starts
with this:

| 24aa07882b (memblock, x86: Replace memblock_x86_reserve/free_range()
| with generic ones) removed arch/x86/include/asm/memblock.h and dropped
| its inclusion from include/linux/memblock.h which breaks other
| architectures which depended on the generic memblock.h pulling in the
| arch specific one.

so, this definition in our asm/memblock.h won't have any effect for much
longer.

Second reason: defining this discards the memblock arrays.  Now look at
this:

#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
        return memblock_is_memory(__pfn_to_phys(pfn));
}
EXPORT_SYMBOL(pfn_valid);
#endif

Third reason: my comment about memblock only being used during early boot
was made because that's the case for using it to do _allocations_, because
once memblock has passed the memory and reserved areas to bootmem, using
memblock _from that point_ means that bootmem will not be updated - and
that in turn means that the kernel's page allocator will also not be
updated correctly.

During boot, memory information is passed thusly:

atags or dt -> memblock -> bootmem -> page allocator

Ideally, we should get rid of bootmem from that sequence, which will make
things a little less complicated - but I believe this is not possible at
the moment due to our use of sparsemem, and iirc sparsemem depends on
certain aspects of bootmem.