On 8/3/23 5:00 PM, Michal Hocko wrote:

On Thu 03-08-23 11:24:08, David Hildenbrand wrote:
[...]

quoted

quoted

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

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.

I guess that closely aligns with device memory and being able to add
device memory via dax/kmem using a larger memory block size.
We can then make sure we enable the memmap_on_memory feature
at the device level for this device memory. Do you see a need for
firmware-managed memory to be hotplugged in with different memory block sizes?

quoted

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.

-aneesh