On Sun, Nov 07, 2021 at 10:21:33AM +0100, David Hildenbrand wrote: > Let's not focus on b), a) is the primary goal of this series: > > " > a) Reduce the metadata overhead, including bitmap sizes inside KVM but > also inside QEMU KVM code where possible. > " > > Because: > > " > For example, when starting a VM with a 1 TiB virtio-mem device that only > exposes little device memory (e.g., 1 GiB) towards the VM initialliy, > in order to hotplug more memory later, we waste a lot of memory on > metadata for KVM memory slots (> 2 GiB!) and accompanied bitmaps. > " > > Partially tackling b) is just a nice side effect of this series. In the > long term, we'll want userfaultfd-based protection, and I'll do a > performance evaluation then, how userfaultf vs. !userfaultfd compares > (boot time, run time, THP consumption). > > I'll adjust the cover letter for the next version to make this clearer. So given this is short-term, and long term we'll use uffd possibly with some extension (a syscall to populate 1G in one go?) isn't there some way to hide this from management? It's a one way street: once we get management involved in playing with memory slots we no longer can go back and control them ourselves. Not to mention it's a lot of complexity to push out to management. -- MST
