[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <305282435.22336766.1491487114644.JavaMail.zimbra@redhat.com>
Date: Thu, 6 Apr 2017 09:58:34 -0400 (EDT)
From: Jerome Glisse <jglisse@...hat.com>
To: Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, John Hubbard <jhubbard@...dia.com>,
Dan Williams <dan.j.williams@...el.com>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
David Nellans <dnellans@...dia.com>,
Russell King <linux@...linux.org.uk>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
Chris Metcalf <cmetcalf@...lanox.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [HMM 01/16] mm/memory/hotplug: add memory type parameter to
arch_add/remove_memory
> > diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> > index 5f84433..0933261 100644
> > --- a/arch/powerpc/mm/mem.c
> > +++ b/arch/powerpc/mm/mem.c
> > @@ -126,14 +126,31 @@ int __weak remove_section_mapping(unsigned long
> > start, unsigned long end)
> > return -ENODEV;
> > }
> >
> > -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
> > +int arch_add_memory(int nid, u64 start, u64 size, enum memory_type type)
> > {
> > struct pglist_data *pgdata;
> > - struct zone *zone;
> > unsigned long start_pfn = start >> PAGE_SHIFT;
> > unsigned long nr_pages = size >> PAGE_SHIFT;
> > + bool for_device = false;
> > + struct zone *zone;
> > int rc;
> >
> > + /*
> > + * Each memory_type needs special handling, so error out on an
> > + * unsupported type. In particular, MEMORY_DEVICE_UNADDRESSABLE
> > + * is not supported on this architecture.
>
> The concept of MEMORY_DEVICE_UNADDRESSABLE has not been
> introduced yet in this patch if I read correctly.
Correct, i did not want to add comment to all the arch file in the patch
that add it because this is one of the most painful patch to rebase so
instead of having more patch that are problematic for rebase i just added
the proper comment ahead of time to make my constant rebasing easier.
Cheers,
Jérôme
Powered by blists - more mailing lists