lkml.org 
[lkml]   [2019]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/4] mm,memory_hotplug: allocate memmap from hotadded memory
    From
    Date
    On 03.04.19 10:12, Michal Hocko wrote:
    > On Wed 03-04-19 10:01:16, Oscar Salvador wrote:
    >> On Tue, Apr 02, 2019 at 02:48:45PM +0200, Michal Hocko wrote:
    >>> So what is going to happen when you hotadd two memblocks. The first one
    >>> holds memmaps and then you want to hotremove (not just offline) it?
    >>
    >> If you hot-add two memblocks, this means that either:
    >>
    >> a) you hot-add a 256MB-memory-device (128MB per memblock)
    >> b) you hot-add two 128MB-memory-device
    >>
    >> Either way, hot-removing only works for memory-device as a whole, so
    >> there is no problem.
    >>
    >> Vmemmaps are created per hot-added operations, this means that
    >> vmemmaps will be created for the hot-added range.
    >> And since hot-add/hot-remove operations works with the same granularity,
    >> there is no problem.
    >
    > What does prevent calling somebody arch_add_memory for a range spanning
    > multiple memblocks from a driver directly. In other words aren't you

    To drivers, we only expose add_memory() and friends. And I think this is
    a good idea.

    > making assumptions about a future usage based on the qemu usecase?
    >

    As I noted, we only have an issue if add add_memory() and
    remove_memory() is called with different granularity. I gave two
    examples where this might not be the case, but we will have to look int
    the details.

    --

    Thanks,

    David / dhildenb

    \
     
     \ /
      Last update: 2019-04-03 10:18    [W:3.758 / U:0.720 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site