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

[David Hildenbrand]

> > I want to warn the user right away that the configuration is messed up and
> > that "reserved=off" is not effective.
> >
> > For anonymous memory, "reserved=off" will start really being useful when
> > having a way to dynamically reserve swap space.
> >
> > > I think it's fine to have that early failure, it just seems less helpful than
> > > what glibc was doing which shrinks active memory for real, meanwhile there
> > > seems to encode some very detailed OS information into this helper, so just
> > > less charming.
> >
> > It's not nice, but the messed-up Linux implementation is to blame. Just read
> > the Linux man page of the mmap where there is an explicit link to
> > "/proc/sys/vm/overcommit_memory" for this very reason.
> >
> > > Btw above [1] "fd != -1 && shared" looks weird to me.
> >
> > As we never have shared anonymous memory (and that's good, because it is
> > super weird) in QEMU, we can simplify to
> >
> > "if (shared) { return true; }"
>
> Yes this looks easier to read.  Maybe you can assert the fd in the block too if
> you are pretty sure of it.

Yes, and I'll also add more comments to clarify.

[...]

> > It's interesting that you also raise this point: I also want to propose
> > dynamic reservation of swap space for shmem in the future. Instead of being
> > per process, this would have to be per file and similar allow to coordinate
> > with the kernel how much memory we are actually intending to use (->commit)
> > such that the kernel can properly account and reject if it wouldn't be
> > possible. If only a single day would have more than 24 hours :)
>
> Thanks, all you said looks sane.
>
> I can't say I fully understand what you'd like to propose.  To me, a sane user
> of /dev/shm should really fallocate() on that before using, but I could also be
> wrong.

Even then, no swap space gets reserved / memory gets accounted; as 
accounting is a bit expensive we don't want to do that on fault/discard 
time. It's still a bit of a puzzle.

Also, fallocate() gets pretty useless once you bring memory overcommit / 
virtio-balloon into the picture :(

> Another trivial suggestion is you can also add these function pointers into the
> comment of the helper, e.g., accountable_mapping() as you referenced.  So it
> would be easier for people to understand where these code came from.

Yes, I'll try adding more comments.

--
Thanks,

David / dhildenb