Re: [patch] fix memmap accounting

[Dave Hansen <haveblue@us.ibm.com>]

On Fri, 2007-01-05 at 15:55 +0100, Heiko Carstens wrote:
> So the calculation of the number of pages needed for the memmap is wrong.
> It just doesn't work with virtual memmaps since it expects that all pages
> of a memmap are actually backed with physical pages which is not the case
> here.
> 
> This patch fixes it, but I guess something similar is also needed for
> SPARSEMEM and ia64 (with vmemmap).
...
> --- linux-2.6.orig/arch/s390/Kconfig
> +++ linux-2.6/arch/s390/Kconfig
> @@ -30,6 +30,9 @@ config ARCH_HAS_ILOG2_U64
>  	bool
>  	default n
> 
> +config ARCH_HAS_VMEMMAP
> +	def_bool y
> +
>  config GENERIC_HWEIGHT
>  	bool
>  	default y
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -2629,7 +2629,11 @@ static void __meminit free_area_init_cor
>  		 * is used by this zone for memmap. This affects the watermark
>  		 * and per-cpu initialisations
>  		 */
> +#ifdef CONFIG_ARCH_HAS_VMEMMAP
> +		memmap_pages = (realsize * sizeof(struct page)) >> PAGE_SHIFT;
> +#else
>  		memmap_pages = (size * sizeof(struct page)) >> PAGE_SHIFT;
> +#endif
>  		if (realsize >= memmap_pages) {
>  			realsize -= memmap_pages;
>  			printk(KERN_DEBUG

I'm not sure this is the right fix.  The same issues should, in theory,
be present for SPARSEMEM systems.  So, doing it by architecture alone is
probably a bad idea.  This also just kinda hacks around the problem.  In
any case, at least ia64 also has vmem_map[]s and needs it too.

I think the correct solution here is to either actually record how many
pages we allocate for mem_map[]s or keep the hole information so that it
can also be referenced in this area of the code.  I think the direct
accounting of how many pages went to mem_map[]s is probably best because
it tackles the problem more directly.  Otherwise, we potentially need to
expose the information about how mem_map[]s cover holes on _each_ of the
methods, and effectively recalculate it here.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>