On 8/3/23 5:00 PM, 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). > > 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? >> 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
