Re: [PATCH v1 00/12] virtio-mem: Expose device memory via multiple memslots

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux