> Ah. I'd missed that quirk around MAX_ORDER. It's also true of ARM64 with > 4k pages. As you can probably guess I'd forgotten to recompile my 4k test > kernel after adding that particular check. :( > > Ah well. Given we are already in a situation where adding 2MiB doesn't > actually > do anything useful, I guess it's not really a problem to merrily let the host > add less than the guest can make use of. So we allow adding any multiple of > 2MiB but reality is the guest isn't going to use anything other than 512MiB > chunks.
Right, and the host can observe the change not happening when not aligned to 512 MB. There are plans for a virtio-mem extension for the guest to present a status - e.g., why the requested size cannot be achieved (requested size not alignment, usable region too small, ENOMEM/EBUSY when unplugging, ...). [...] >>> >>> 4K guest on 64K host seems fine and no such limit is needed - though there >>> may be performance issues doing that. >> >> Yeah, if one is lucky to get one of these 512 MiB huge pages at all :) > > Not too hard on my 1TB test system that's running nothing much else, but > agreed it > won't be trivial more generally. Hehe, right ! (... and here I am, testing with 64GB machines ... :) ) It's more of an issue in the guest to get 512 MB without ZONE_MOVABLE to unplug ... especially with smaller VMs. > >> >>> >>> 64k guest on 4k host with 512MiB block size seems fine. >>> >>> If there are any places anyone thinks need particular poking I'd appreciate >>> a hint :) >> >> If things seem to work for now, that's great :) Thanks! >> > Cool. I'll run a few more comprehensive tests then send out the > trivial patch to enable the kernel option + v2 of the qemu support. Perfect, thanks! -- Thanks, David / dhildenb
