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 17:39:42 +1000 [thread overview]
Message-ID: <1377589182.3819.117.camel@pasglop> (raw)
In-Reply-To: <1377575091.3819.97.camel@pasglop>
On Tue, 2013-08-27 at 13:44 +1000, Benjamin Herrenschmidt wrote:
> 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 ?
Bah, call me an idiot ... I was looking at the code without your patch
and not realizing that this is exactly what your patch does :-)
.../...
> 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 still stands, should we actually "register" the pages of the
vmemmap or not ?
What happens if we remove a chunk of memory and then plug it back in ?
Will it try to re-create a new vmemmap chunk for that area (where we
haven't removed the previous one) ? That might cause problems if we end
up putting duplicate entries in the hash table ... should we implement
vmemmap_free and actual unmap the segments ?
> 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
>
prev parent reply other threads:[~2013-08-27 7:39 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
2013-08-27 7:39 ` Benjamin Herrenschmidt [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=1377589182.3819.117.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.