>> >> Both changes only make sense with an in-tree user. I'm planning on using >> this functionality in virtio-mem code. I can pickup your patches, drop >> the superfluous checks, and use it from virtio-mem code. Makese sense >> (BTW, looks like we'll see aarch64 support for virtio-mem soon)? > > I have not been following virtio-mem closely. But is there something pending > on arm64 platform which prevents virtio-mem enablement ? Regarding enablement, I expect things to be working out of the box mostly. Jonathan is currently doing some testing and wants to send a simple unlock patch once done. [1] Now, there are some things to improve in the future. virtio-mem adds/removes individual Linux memory blocks and logically plugs/unplugs MAX_ORDER - 1/pageblock_order pages inside Linux memory blocks. 1. memblock On arm64 and powerpc, we create/delete memblocks when adding/removing memory, which is suboptimal (and the code is quite fragile as we don't handle errors ...). Hotplugged memory never has holes, so we can tweak relevant code to not check via the memblock api. For example, pfn_valid() only has to check for memblock_is_map_memory() in case of !early_section() - otherwise it can just fallback to our generic pfn_valid() function. 2. MAX_ORDER - 1 / pageblock_order With 64k base pages, virtio-mem can only logically plug/unplug in 512MB granularity, which is sub-optimal and inflexible. 4/2MB would be much better - however this would require always using 2MB THP on arm64 (IIRC via "cont" bits). Luckily, only some distributions use 64k base pages as default nowadays ... :) 3. Section size virtio-mem benefits from small section sizes. Currently, we have 1G. With 4k base pages we could easily reduce it to something what x86 has (128 MB) - and I remember discussions regarding that already in other (IIRC NVDIMM / DIMM) context. Again, with 64k base pages we cannot go below 512 MB right now. [1] https://lkml.kernel.org/r/20201125145659.00004b3e@xxxxxxxxxx -- Thanks, David / dhildenb
