On 03.08.23 13:30, Michal Hocko wrote:
On Thu 03-08-23 11:24:08, David Hildenbrand wrote:
[...]
would be readable only when the block is offline and it would reallocate
vmemmap on the change. Makes sense? Are there any risks? Maybe pfn
walkers?
The question is: is it of any real value such that it would be worth the
cost and risk?
One of the primary reasons for memmap_on_memory is that *memory hotplug*
succeeds even in low-memory situations (including, low on ZONE_NORMAL
situations).
Sorry for the late reply, I'm busy with 100 other things.
One usecase I would have in mind is a mix of smaller and larger memory
blocks. For larger ones you want to have memmap_on_memory in general
because they do not eat memory from outside but small(er) ones might be
more tricky because now you can add a lot of blocks that would be
internally fragmented to prevent larger allocations to form.
Okay, I see what you mean.
The internal fragmentation might become an issue at some point: for
x86-64 with 128 MiB blocks / 2 MiB THP it's not a real issue right now.
For a arm64 64k with 512 MiB blocks and 512 MiB THP / hugelb it could be
one.
I recall discussing that with Oscar back when he added memmap_on_memory,
where we also discussed the variable-sized memory blocks to avoid such
internal fragmentation.
For small ones you probably want to only use memmap_on_memory when
unavoidable: for example, when adding without memmap_on_memory would
fail / already failed. Possibly some later memmap relocation might make
sense in some scenarios.
So you want that behavior already when hotplugging such
devices. While there might be value to relocate it later, I'm not sure if
that is really worth it, and it does not solve the main use case.
Is it worth it? TBH I am not sure same as I am not sure the global
default should be writable after boot. If we want to make it more
dynamic we should however talk about the proper layer this is
implemented on.
Agreed.
--
Cheers,
David / dhildenb
