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

[David Hildenbrand <david@redhat.com>]

>> 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