linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@kernel.org>
Cc: David Hildenbrand <david@redhat.com>,
	akpm@linux-foundation.org, 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 0/4] mm,memory_hotplug: allocate memmap from hotadded memory
Date: Tue, 2 Apr 2019 10:28:15 +0200	[thread overview]
Message-ID: <20190402082812.fefamf7qlzulb7t2@d104.suse.de> (raw)
In-Reply-To: <20190401115306.GF28293@dhcp22.suse.cz>

On Mon, Apr 01, 2019 at 01:53:06PM +0200, Michal Hocko wrote:
> On Mon 01-04-19 09:59:36, Oscar Salvador wrote:
> > On Fri, Mar 29, 2019 at 02:42:43PM +0100, Michal Hocko wrote:
> > > Having a larger contiguous area is definitely nice to have but you also
> > > have to consider the other side of the thing. If we have a movable
> > > memblock with unmovable memory then we are breaking the movable
> > > property. So there should be some flexibility for caller to tell whether
> > > to allocate on per device or per memblock. Or we need something to move
> > > memmaps during the hotremove.
> > 
> > By movable memblock you mean a memblock whose pages can be migrated over when
> > this memblock is offlined, right?
> 
> I am mostly thinking about movable_node kernel parameter which makes
> newly hotpluged memory go into ZONE_MOVABLE and people do use that to
> make sure such a memory can be later hotremoved.

Uhm, I might be missing your point, but hot-added memory that makes use of
vmemmap pages can be hot-removed as any other memory.

Vmemmap pages do not account as unmovable memory, they just stick around
until all sections they referred to have been removed, and then, we proceed
with removing them.
So, to put it in another way: vmemmap pages are left in the system until the
whole memory device (DIMM, virt mem-device or whatever) is completely
hot-removed.

-- 
Oscar Salvador
SUSE L3


  reply	other threads:[~2019-04-02  8:28 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
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 [this message]
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=20190402082812.fefamf7qlzulb7t2@d104.suse.de \
    --to=osalvador@suse.de \
    --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=mhocko@kernel.org \
    /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).