Hi Pasha,
Coming from the virtio-pmem and some free page hinting background, I am
interested in this discussion. I saw your proposal about single owner
memory driver in other thread and could not entirely link the dots about
applicability of the idea with "reducing the memory footprint overhead
for virtual machines". Do we plan to co-ordinate guest memory state with
corresponding host state for efficient memory reclaim decisions?
Or something entirely different we are targeting here?
Hi Pankaj,
The plan is to have a driver /dev/memctl and corresponding VMM agent
that synchronously passes information about how guest would like its
memory to be backed on the host.
For example the following information can come from guest for a range
of physical addresses:
MADV_NOHUGEPAGE
MADV_HUGEPAGE
MADV_DONTNEED
PR_SET_VMA_ANON_NAME
etc.
All together this should help by doing memory management operations
only on the host side, and reduce the number of operations that are
performed on the guest.
o.k. That sounds like guest will have a *special* interface (paravirt?)
for some of the memory management operations with the coordination of host.
That is correct, hence memory passthrough.
ya.
Guest would still allow other regular memory operations? which would get
full-filled by the guest? Just wondering if this solution only be
useful for specific workloads which are aware of known MADV calls?
Depending on the flexibility of the interface, we are currently
working supporting tcmalloc(), and also mmap(MAP_ANONYMOUS), but in
the future can be extended to more types of memory.
Not sure if its worth to extend the existing paravirt memory management
interfaces like virtio-mem or virtio-balloon or create a new driver
altogether? Adding David (in Cc) for his thoughts.
Thanks,
Pankaj
And might not do/require continuous allocation/deallocation of memory?
Contiguous memory allocation on the host is not required.
Thanks,
Pasha
