[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 11/14] util/mmap-alloc: Support RAM_NORESERVE via MAP_NORE
From: |
Peter Xu |
Subject: |
Re: [PATCH v4 11/14] util/mmap-alloc: Support RAM_NORESERVE via MAP_NORESERVE under Linux |
Date: |
Tue, 23 Mar 2021 16:56:29 -0400 |
On Fri, Mar 19, 2021 at 11:12:27AM +0100, David Hildenbrand wrote:
> Let's support RAM_NORESERVE via MAP_NORESERVE on Linux. The flag has no
> effect on most shared mappings - except for hugetlbfs and anonymous memory.
>
> Linux man page:
> "MAP_NORESERVE: Do not reserve swap space for this mapping. When swap
> space is reserved, one has the guarantee that it is possible to modify
> the mapping. When swap space is not reserved one might get SIGSEGV
> upon a write if no physical memory is available. See also the discussion
> of the file /proc/sys/vm/overcommit_memory in proc(5). In kernels before
> 2.6, this flag had effect only for private writable mappings."
>
> Note that the "guarantee" part is wrong with memory overcommit in Linux.
>
> Also, in Linux hugetlbfs is treated differently - we configure reservation
> of huge pages from the pool, not reservation of swap space (huge pages
> cannot be swapped).
>
> The rough behavior is [1]:
> a) !Hugetlbfs:
>
> 1) Without MAP_NORESERVE *or* with memory overcommit under Linux
> disabled ("/proc/sys/vm/overcommit_memory == 2"), the following
> accounting/reservation happens:
> For a file backed map
> SHARED or READ-only - 0 cost (the file is the map not swap)
> PRIVATE WRITABLE - size of mapping per instance
>
> For an anonymous or /dev/zero map
> SHARED - size of mapping
> PRIVATE READ-only - 0 cost (but of little use)
> PRIVATE WRITABLE - size of mapping per instance
>
> 2) With MAP_NORESERVE, no accounting/reservation happens.
>
> b) Hugetlbfs:
>
> 1) Without MAP_NORESERVE, huge pages are reserved.
>
> 2) With MAP_NORESERVE, no huge pages are reserved.
>
> Note: With "/proc/sys/vm/overcommit_memory == 0", we were already able
> to configure it for !hugetlbfs globally; this toggle now allows
> configuring it more fine-grained, not for the whole system.
>
> The target use case is virtio-mem, which dynamically exposes memory
> inside a large, sparse memory area to the VM.
>
> [1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
- [PATCH v4 05/14] util/mmap-alloc: Factor out reserving of a memory region to mmap_reserve(), (continued)
- [PATCH v4 05/14] util/mmap-alloc: Factor out reserving of a memory region to mmap_reserve(), David Hildenbrand, 2021/03/19
- [PATCH v4 06/14] util/mmap-alloc: Factor out activating of memory to mmap_activate(), David Hildenbrand, 2021/03/19
- [PATCH v4 07/14] softmmu/memory: Pass ram_flags to qemu_ram_alloc_from_fd(), David Hildenbrand, 2021/03/19
- [PATCH v4 08/14] softmmu/memory: Pass ram_flags to memory_region_init_ram_shared_nomigrate(), David Hildenbrand, 2021/03/19
- [PATCH v4 09/14] util/mmap-alloc: Pass flags instead of separate bools to qemu_ram_mmap(), David Hildenbrand, 2021/03/19
- [PATCH v4 10/14] memory: Introduce RAM_NORESERVE and wire it up in qemu_ram_mmap(), David Hildenbrand, 2021/03/19
- [PATCH v4 11/14] util/mmap-alloc: Support RAM_NORESERVE via MAP_NORESERVE under Linux, David Hildenbrand, 2021/03/19
- Re: [PATCH v4 11/14] util/mmap-alloc: Support RAM_NORESERVE via MAP_NORESERVE under Linux,
Peter Xu <=
- [PATCH v4 12/14] hostmem: Wire up RAM_NORESERVE via "reserve" property, David Hildenbrand, 2021/03/19
- [PATCH v4 13/14] qmp: Include "reserve" property of memory backends, David Hildenbrand, 2021/03/19
[PATCH v4 14/14] hmp: Print "reserve" property of memory backends with "info memdev", David Hildenbrand, 2021/03/19