All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Oscar Salvador <osalvador@suse.com>
Cc: linux-mm@kvack.org, david@redhat.com, rppt@linux.vnet.ibm.com,
	akpm@linux-foundation.org, arunks@codeaurora.org, bhe@redhat.com,
	dan.j.williams@intel.com, Pavel.Tatashin@microsoft.com,
	Jonathan.Cameron@huawei.com, jglisse@redhat.com,
	linux-kernel@vger.kernel.org, Oscar Salvador <osalvador@suse.de>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>
Subject: Re: [RFC PATCH 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug
Date: Fri, 23 Nov 2018 14:00:43 +0100	[thread overview]
Message-ID: <20181123130043.GM8625@dhcp22.suse.cz> (raw)
In-Reply-To: <20181116101222.16581-3-osalvador@suse.com>

[Cc Alexander - email thread starts http://lkml.kernel.org/r/20181116101222.16581-1-osalvador@suse.com]

On Fri 16-11-18 11:12:20, 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. This is currently done quite ugly by searching for altmap down
> in memory hotplug (to_vmem_altmap). It should be the caller to provide
> the altmap down the call chain.
> 
> 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.

One note here as well. In the retrospect the API I have come up
with here is quite hackish. Considering the recent discussion about
special needs ZONE_DEVICE has for both initialization and struct page
allocations with Alexander Duyck I believe we wanted a more abstracted
API with allocator and constructor callbacks. This would allow different
usecases to fine tune their needs without specialcasing deep in the core
hotplug code paths.
-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2018-11-23 13:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-16 10:12 [RFC PATCH 0/4] mm, memory_hotplug: allocate memmap from hotadded memory Oscar Salvador
2018-11-16 10:12 ` [RFC PATCH 1/4] mm, memory_hotplug: cleanup memory offline path Oscar Salvador
2018-11-16 10:12 ` [RFC PATCH 2/4] mm, memory_hotplug: provide a more generic restrictions for memory hotplug Oscar Salvador
2018-11-16 21:39   ` Dave Hansen
2018-11-23 13:00   ` Michal Hocko [this message]
2019-01-14 13:17     ` Oscar Salvador
2018-11-16 10:12 ` [RFC PATCH 3/4] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Oscar Salvador
2018-11-16 22:41   ` Dave Hansen
2018-11-16 22:41     ` Dave Hansen
2018-11-18 22:54     ` osalvador
2018-11-16 10:12 ` [RFC PATCH 4/4] mm, sparse: rename kmalloc_section_memmap, __kfree_section_memmap Oscar Salvador
2018-11-22  9:21 ` [RFC PATCH 0/4] mm, memory_hotplug: allocate memmap from hotadded memory David Hildenbrand
2018-11-23 11:55   ` Oscar Salvador
2018-11-23 12:11     ` David Hildenbrand
2018-11-23 12:42     ` Michal Hocko
2018-11-23 12:51       ` David Hildenbrand
2018-11-23 13:12         ` Michal Hocko
2018-11-26 13:05     ` David Hildenbrand

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=20181123130043.GM8625@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Pavel.Tatashin@microsoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=arunks@codeaurora.org \
    --cc=bhe@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.com \
    --cc=osalvador@suse.de \
    --cc=rppt@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.