Re: [PATCH v1 8/9] util/mmap-alloc: support RAM_NORESERVE via MAP_NORESERVE

[David Hildenbrand]

On 02.03.21 18:51, Peter Xu wrote:
> On Tue, Feb 09, 2021 at 02:49:38PM +0100, David Hildenbrand wrote:
> > +#define OVERCOMMIT_MEMORY_PATH "/proc/sys/vm/overcommit_memory"
> > +static bool map_noreserve_effective(int fd, bool shared)
> > +{
> > +#if defined(__linux__)
> > +    gchar *content = NULL;
> > +    const char *endptr;
> > +    unsigned int tmp;
> > +
> > +    /* hugetlbfs behaves differently */
> > +    if (qemu_fd_getpagesize(fd) != qemu_real_host_page_size) {
> > +        return true;
> > +    }
> > +
> > +    /* only private shared mappings are accounted (ignoring /dev/zero) */
> > +    if (fd != -1 && shared) {
> > +        return true;
> > +    }
> > +
> > +    if (g_file_get_contents(OVERCOMMIT_MEMORY_PATH, &content, NULL, NULL) &&
> > +        !qemu_strtoui(content, &endptr, 0, &tmp) &&
> > +        (!endptr || *endptr == '\n')) {
> > +        if (tmp == 2) {
> > +            error_report("Skipping reservation of swap space is not supported: 
> > "
> > +                         " \"" OVERCOMMIT_MEMORY_PATH "\" is \"2\"");
> > +            return false;
> > +        }
> > +        return true;
> > +    }
> > +    /* this interface has been around since Linux 2.6 */
> > +    error_report("Skipping reservation of swap space is not supported: "
> > +                 " Could not read: \"" OVERCOMMIT_MEMORY_PATH "\"");
> > +    return false;
> > +#else
> > +    return true;
> > +#endif
> > +}
>
> I feel like this helper wants to fail gracefully for some conditions.  Could
> you elaborate one example and attach to the commit log?

Sure. The case is "/proc/sys/vm/overcommit_memory == 2" (never overcommit)

MAP_NORESERVE is without effect and sparse memory regions are somewhat 
impossible.

> I'm also wondering whether it would worth to check the global value.  Even if
> overcommit is globally disabled, do we (as an application process) need to care
> about it?  I think the MAP_NORESERVE would simply be silently ignored by the
> kernel and that seems to be design of it, otherwise would all apps who uses > 
> MAP_NORESERVE would need to do similar things too?

Right, I want to catch the "gets silently ignored" part, because someone 
requested "reserved=off" (!default) but does not actually get what he 
asked for.

As one example, glibc manages heaps via:

a) Creating a new heap: mmap(PROT_NONE, MAP_NORESERVE) the maximum size, 
then mprotect(PROT_READ|PROT_WRITE) the initial heap size. Even if 
MAP_NORESERVE is ignored, only !PROT_NONE memory ever gets committed 
("reserve swap space") in Linux.

b) Growing the heap via mprotect(PROT_READ|PROT_WRITE) within the 
existing mmap. This will commit memory in case MAP_NORESERVE got ignored.

c) Shrinking the heap ("discard memory") via MADV_DONTNEED *unless* 
"/proc/sys/vm/overcommit_memory == 2" - the only way to undo 
mprotect(PROT_READ|PROT_WRITE) and to un-commit memory is by doing a 
mmap(PROT_NONE, MAP_FIXED) over the problematic region.

If you're interested, you can take a look at:

malloc/arena.c
sysdeps/unix/sysv/linux/malloc-sysdep.h:check_may_shrink_heap()


Thanks!

--
Thanks,

David / dhildenb