[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1542373433.3020.19.camel@suse.de>
Date: Fri, 16 Nov 2018 14:03:53 +0100
From: osalvador <osalvador@...e.de>
To: Dan Williams <dan.j.williams@...el.com>,
osalvador@...hadventures.net
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Yasuaki Ishimatsu <yasu.isimatu@...il.com>,
rppt@...ux.vnet.ibm.com, malat@...ian.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Pasha Tatashin <pavel.tatashin@...rosoft.com>,
Jérôme Glisse <jglisse@...hat.com>,
Jonathan.Cameron@...wei.com,
"Rafael J. Wysocki" <rafael@...nel.org>,
David Hildenbrand <david@...hat.com>,
Dave Jiang <dave.jiang@...el.com>,
Linux MM <linux-mm@...ck.org>,
alexander.h.duyck@...ux.intel.com
Subject: Re: [PATCH 2/5] mm/memory_hotplug: Create add/del_device_memory
functions
> This collides with the refactoring of hmm, to be done in terms of
> devm_memremap_pages(). I'd rather not introduce another common
> function *beneath* hmm and devm_memremap_pages() and rather make
> devm_memremap_pages() the common function.
Hi Dan,
That is true.
Previous version of this patchet was based on yours (hmm-refactor),
but then I decided to not base it here due to lack of feedback.
But if devm_memremap_pages() is going to be the main/common function,
I am totally fine to put the memory-hotplug specific there.
> I plan to resubmit that cleanup after Plumbers. So, unless I'm
> misunderstanding some other benefit a nak from me on this patch as it
> stands currently.
Great, then I will wait for your new patchset, and then I will base
this one on that.
Thanks
Oscar Salvador
Powered by blists - more mailing lists