From: Michal Hocko <mhocko@kernel.org>
To: Oscar Salvador <osalvador@suse.de>
Cc: akpm@linux-foundation.org, david@redhat.com,
dan.j.williams@intel.com, Jonathan.Cameron@huawei.com,
anshuman.khandual@arm.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug
Date: Wed, 3 Apr 2019 10:46:03 +0200 [thread overview]
Message-ID: <20190403084603.GE15605@dhcp22.suse.cz> (raw)
In-Reply-To: <20190328134320.13232-3-osalvador@suse.de>
On Thu 28-03-19 14:43:18, Oscar Salvador wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> arch_add_memory, __add_pages take a want_memblock which controls whether
> the newly added memory should get the sysfs memblock user API (e.g.
> ZONE_DEVICE users do not want/need this interface). Some callers even
> want to control where do we allocate the memmap from by configuring
> altmap.
>
> Add a more generic hotplug context for arch_add_memory and __add_pages.
> struct mhp_restrictions contains flags which contains additional
> features to be enabled by the memory hotplug (MHP_MEMBLOCK_API
> currently) and altmap for alternative memmap allocator.
>
> Please note that the complete altmap propagation down to vmemmap code
> is still not done in this patch. It will be done in the follow up to
> reduce the churn here.
>
> This patch shouldn't introduce any functional change.
Is there an agreement on the interface here? Or do we want to hide almap
behind some more general looking interface? If the former is true, can
we merge it as it touches a code that might cause merge conflicts later on
as multiple people are working on this area.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-04-03 8:46 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 13:43 [PATCH 0/4] mm,memory_hotplug: allocate memmap from hotadded memory Oscar Salvador
2019-03-28 13:43 ` [PATCH 1/4] mm, memory_hotplug: cleanup memory offline path Oscar Salvador
2019-04-03 8:43 ` Michal Hocko
2019-03-28 13:43 ` [PATCH 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug Oscar Salvador
2019-04-03 8:46 ` Michal Hocko [this message]
2019-04-03 8:48 ` David Hildenbrand
2019-04-04 10:04 ` Oscar Salvador
2019-04-04 10:06 ` David Hildenbrand
2019-04-04 10:31 ` Michal Hocko
2019-04-04 12:04 ` Oscar Salvador
2019-03-28 13:43 ` [PATCH 3/4] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Oscar Salvador
2019-03-28 13:43 ` [PATCH 4/4] mm, sparse: rename kmalloc_section_memmap, __kfree_section_memmap Oscar Salvador
2019-03-28 15:09 ` [PATCH 0/4] mm,memory_hotplug: allocate memmap from hotadded memory David Hildenbrand
2019-03-28 15:31 ` David Hildenbrand
2019-03-29 8:45 ` Oscar Salvador
2019-03-29 8:56 ` David Hildenbrand
2019-03-29 9:01 ` David Hildenbrand
2019-03-29 9:20 ` Oscar Salvador
2019-03-29 13:42 ` Michal Hocko
2019-04-01 7:59 ` Oscar Salvador
2019-04-01 11:53 ` Michal Hocko
2019-04-02 8:28 ` Oscar Salvador
2019-04-02 8:39 ` David Hildenbrand
2019-04-02 12:48 ` Michal Hocko
2019-04-03 8:01 ` Oscar Salvador
2019-04-03 8:12 ` Michal Hocko
2019-04-03 8:17 ` David Hildenbrand
2019-04-03 8:37 ` Michal Hocko
2019-04-03 8:41 ` David Hildenbrand
2019-04-03 8:49 ` Michal Hocko
2019-04-03 8:53 ` David Hildenbrand
2019-04-03 8:50 ` Oscar Salvador
2019-04-03 8:54 ` David Hildenbrand
2019-04-03 9:40 ` Oscar Salvador
2019-04-03 10:46 ` Michal Hocko
2019-04-04 10:25 ` Vlastimil Babka
2019-04-03 8:34 ` Oscar Salvador
2019-04-03 8:36 ` David Hildenbrand
2019-03-29 8:30 ` Oscar Salvador
2019-03-29 8:51 ` David Hildenbrand
2019-03-29 22:23 ` John Hubbard
2019-04-01 7:52 ` Oscar Salvador
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=20190403084603.GE15605@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).