lkml.org 
[lkml]   [2021]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory
    Date
    On 18.02.21 23:59, Peter Xu wrote:
    > Hi, David,
    >
    > On Wed, Feb 17, 2021 at 04:48:44PM +0100, David Hildenbrand wrote:
    >> When we manage sparse memory mappings dynamically in user space - also
    >> sometimes involving MADV_NORESERVE - we want to dynamically populate/
    >> discard memory inside such a sparse memory region. Example users are
    >> hypervisors (especially implementing memory ballooning or similar
    >> technologies like virtio-mem) and memory allocators. In addition, we want
    >> to fail in a nice way if populating does not succeed because we are out of
    >> backend memory (which can happen easily with file-based mappings,
    >> especially tmpfs and hugetlbfs).
    >
    > Could you explain a bit more on how do you plan to use this new interface for
    > the virtio-balloon scenario?

    Sure, that will bring up an interesting point to discuss
    (MADV_POPULATE_WRITE).

    I'm planning on using it in virtio-mem: whenever the guests requests the
    hypervisor (via a virtio-mem device) to make specific blocks available
    ("plug"), I want to have a configurable option ("populate=on" /
    "prealloc="on") to perform safety checks ("prealloc") and populate page
    tables.

    This becomes especially relevant for private/shared hugetlbfs and shared
    files/shmem where we have a limited pool size (e.g., huge pages, tmpfs
    size, filesystem size). But it will also come in handy when just
    preallocating (esp. zeroing) anonymous memory.

    For virito-balloon it is not applicable because it really only supports
    anonymous memory and we cannot fail requests to deflate ...

    --- Example ---

    Example: Assume the guests requests to make 128 MB available and we're
    using hugetlbfs. Assume we're out of huge pages in the hypervisor - we
    want to fail the request - I want to do some kind of preallocation.

    So I could do fallocate() on anything that's MAP_SHARED, but not on
    anything that's MAP_PRIVATE. hugetlbfs via memfd() cannot be
    preallocated without going via SIGBUS handlers.

    --- QEMU memory configurations ---

    I see the following combinations relevant in QEMU that I want to support
    with virito-mem:

    1) MAP_PRIVATE anonymous memory
    2) MAP_PRIVATE on hugetlbfs (esp. via memfd)
    3) MAP_SHARED on hugetlbfs (esp. via memfd)
    4) MAP_SHARED on shmem (file / memfd)
    5) MAP_SHARED on some sparse file.

    Other MAP_PRIVATE mappings barely make any sense to me - "read the file
    and write to page cache" is not really applicable to VM RAM (not to
    mention doing fallocate(PUNCH_HOLE) that invalidates the private copies
    of all other mappings on that file).

    --- Ways to populate/preallocate ---

    I see the following ways to populate/preallocate:

    a) MADV_POPULATE: write fault on writable MAP_PRIVATE, read fault on
    MAP_SHARED
    b) Writing to MAP_PRIVATE | MAP_SHARED from user space.
    c) (below) MADV_POPULATE_WRITE: write fault on writable MAP_PRIVATE |
    MAP_SHARED

    Especially, 2) is kind of weird as implemented in QEMU
    (util/oslib-posix.c:do_touch_pages):

    "Read & write back the same value, so we don't corrupt existing user/app
    data ... TODO: get a better solution from kernel so we don't need to
    write at all so we don't cause wear on the storage backing the region..."

    So if we have zero, we write zero. We'll COW pages, triggering a write
    fault - and that's the only good thing about it. For example, similar to
    MADV_POPULATE, nothing stops KSM from merging anonymous pages again. So
    for anonymous memory the actual write is not helpful at all. Similarly
    for hugetlbfs, the actual write is not necessary - but there is no other
    way to really achieve the goal.

    --- How MADV_POPULATE is useful ---

    With virito-mem, our VM will usually write to memory before it reads it.

    With 1) and 2) it does exactly what I want: trigger COW / allocate
    memory and trigger a write fault. The only issue with 1) is that KSM
    might come around and undo our work - but that could only be avoided by
    writing random numbers to all pages from user space. Or we could simply
    rather disable KSM in that setup ...

    --- How MADV_POPULATE is not perfect ---

    KSM can merge anonymous pages again. Just like the current QEMU
    implementation. The only way around that is writing random numbers to
    the pages or mlocking all memory. No big news.

    Nothing stops reclaim/swap code from depopulating when using files.
    Again, no big new - we have to mlock.

    --- HOW MADV_POPULATE_WRITE might be useful ---

    With 3) 4) 5) MADV_POPULATE does partially what I want: preallocate
    memory and populate page tables. But as it's a read fault, I think we'll
    have another minor fault on access. Not perfect, but better than failing
    with SIGBUS. One way around that would be having an additional
    MADV_POPULATE_WRITE, to use in cases where it makes sense (I think at
    least 3) and 4), most probably not on actual files like 5) ).

    Trigger a write fault without actually writing.


    Makes sense?

    --
    Thanks,

    David / dhildenb

    \
     
     \ /
      Last update: 2021-02-19 09:23    [W:9.563 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site