On 22.01.21 23:03, Daniel Henrique Barboza wrote:
On 1/22/21 6:19 PM, David Hildenbrand wrote:
Out of curiosity: are you aware of anyone working in enabling virtio-mem for pseries/ppc64? I'm wondering if there's some kind of architecture limitation in Power or if it's just a lack of interest.
I remember there is interest, however:
- arm64 and x86-64 is used more frequently in applicable (cloud?) setups, so it has high prio - s390x doesn‘t have any proper memory hot(un)plug, and as I have a strong s399x background, it‘s rather easy for me to implement - ppc64 at least supports hot(un)plug of DIMMs
There is nothing fundamental speaking against ppc64 support AFAIR.
That's good to hear.
A block size of 16MB should be possible. I‘m planning on looking into it, however, there are a lot of other things on my todo list for virtio-mem.
I'm not familiar with the 'block size' concept of the virtio-mem device that would allow for 16MB increments. My knowledge of the pseries kernel/QEMU is that the guest visible memory must always be 256MiB aligned due to PAPR mechanics that forces a memory block to be at least this size. Albeit I believe that there is no constraints of the memory this device is providing being counted as non-hotplugable, then in this case the alignment shouldn't be needed.
In Linux guests, virtio-mem adds whole memory blocks (e.g., aligned 256MB), but is able to expose only parts of a memory block dynamically to Linux mm - essentially in 16MB on ppc64 IIRC. E.g., on x86-64 (and soon arm64), we mostly add 128MB memory blocks, but can operate on (currently) 4MB blocks (MAX_ORDER - 1) inside these blocks. A little like memory ballooning ... but also quite different :) So far the theory on ppc64. I have no prototype on ppc64, so we'll have to see what's actually possible.
But I digress. Thanks for the insights. I'll ping some people inside IBM and see if we have a more immediate use case for virtio-mem in Power. Perhaps we can do some sort of collaboration with your work.
Sure, I'll be happy to assist. -- Thanks, David / dhildenb