All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] Register bootmem pages
Date: Tue, 27 Aug 2013 13:44:51 +1000	[thread overview]
Message-ID: <1377575091.3819.97.camel@pasglop> (raw)
In-Reply-To: <5212DA31.2060105@linux.vnet.ibm.com>

On Mon, 2013-08-19 at 21:53 -0500, Nathan Fontenot wrote:
> Previous commit 46723bfa540... introduced a new config option
> HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
> when sparse vmemmap is not defined.
> 
> This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
> register_page_bootmem_info_node. Without this we get a BUG_ON for memory
> hot remove in put_page_bootmem().
> 
> This also adds a stub for register_page_bootmem_memmap to allow ppc to build
> with sparse vmemmap defined.
> 
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> ---

So I still feel very uncomfortable with that stuff ....

For example, x86 calls register_page_bootmem_info_node() at boot time,
which does that strange "get_page_bootmem" on the NODE_DATA itself at
boot time, we don't. Should we ?

Since we don't, what do that mean ? We don't remove the node info pages
on unplug ? Is that ok ?

There's a whole pile of totally undocumented / uncommented generic code
with horrible function names in there whose sematic is very very
unclear.

Now, if we call that thing, are we expected to have
register_paqe_bootmem_memmap() to actually do something right? I assume
that means actually calling get_page_bootmem() on the various struct
page that comprise the vmemmap.

Well, we can probably implement that since we maintain a list of all the
vmemap pages... However, we don't implement vmemmap_free(). Should we ?

This all confuses me...

Cheers,
Ben.

> 
> ---
>  arch/powerpc/mm/init_64.c |    4 ++++
>  arch/powerpc/mm/mem.c     |    9 +++++++++
>  mm/Kconfig                |    2 +-
>  3 files changed, 14 insertions(+), 1 deletion(-)
> 
> Index: linux/arch/powerpc/mm/init_64.c
> ===================================================================
> --- linux.orig/arch/powerpc/mm/init_64.c
> +++ linux/arch/powerpc/mm/init_64.c
> @@ -300,5 +300,9 @@ void vmemmap_free(unsigned long start, u
>  {
>  }
> 
> +void register_page_bootmem_memmap(unsigned long section_nr,
> +				  struct page *start_page, unsigned long size)
> +{
> +}
>  #endif /* CONFIG_SPARSEMEM_VMEMMAP */
> 
> Index: linux/arch/powerpc/mm/mem.c
> ===================================================================
> --- linux.orig/arch/powerpc/mm/mem.c
> +++ linux/arch/powerpc/mm/mem.c
> @@ -297,12 +297,21 @@ void __init paging_init(void)
>  }
>  #endif /* ! CONFIG_NEED_MULTIPLE_NODES */
> 
> +static void __init register_page_bootmem_info(void)
> +{
> +	int i;
> +
> +	for_each_online_node(i)
> +		register_page_bootmem_info_node(NODE_DATA(i));
> +}
> +
>  void __init mem_init(void)
>  {
>  #ifdef CONFIG_SWIOTLB
>  	swiotlb_init(0);
>  #endif
> 
> +	register_page_bootmem_info();
>  	high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
>  	set_max_mapnr(max_pfn);
>  	free_all_bootmem();
> Index: linux/mm/Kconfig
> ===================================================================
> --- linux.orig/mm/Kconfig
> +++ linux/mm/Kconfig
> @@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
>  config MEMORY_HOTREMOVE
>  	bool "Allow for memory hot remove"
>  	select MEMORY_ISOLATION
> -	select HAVE_BOOTMEM_INFO_NODE if X86_64
> +	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
>  	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
>  	depends on MIGRATION
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

  reply	other threads:[~2013-08-27  3:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20  2:50 [PATCH v2] Correct Memory Hotplug for Power Nathan Fontenot
2013-08-20  2:52 ` [PATCH v2 1/2] Mark Memory Resources as busy Nathan Fontenot
2013-08-20  2:53 ` [PATCH v2 2/2] Register bootmem pages Nathan Fontenot
2013-08-27  3:44   ` Benjamin Herrenschmidt [this message]
2013-08-27  7:39     ` Benjamin Herrenschmidt

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=1377575091.3819.97.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nfont@linux.vnet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.