Anyway, it'd be better to get some numbers with RL or agent workloads
(especially the host memory is under reasonable pressure) before
landing all these new infras upstream if proceeding in this way.
At least for now, as far as I'm concerned, I don't intend to land all the
features mentioned here. The first thing I want to address is on-demand
allocation of struct page.
From my point of view, on-demend allocation of `struct page` for FSDAX
is indeed useful and can be landed upstream, mainly because `struct page`
initialization takes much long time for large FSDAX devices even a small
range is used, that impacts the guest startup time a lot.
Would on-demand allocation of 'struct page' from the device itself (a
variant of the altmap case) solve this problem?
For virtio-pmem, since device memory is backed by host page cache. So,
in the worst case host will provide memory for all the 'struct pages',
but the guest itself won't OOM.
Just sharing this idea. Anything I am missing? It could be another
optimization on top of Muchun's work.
Thanks,
Pankaj
But in order to make it safe for production, I suggest reserve the
guest memory in advance for the worst cases of `struct page` at the first
stage, otherwise it could cause unexpected issues for many guest workloads:
it's hard to perdict if the guest memory is still enough, it's unfriendly
to system designers as well (that would completely based on their
experience and hard to ensure the service quality beforehand.)
Since the guest memory for `struct page` is touched on-demand, the memory
over-committing on the host is still workable, the memory reservation
can be removed after the reclaim path is done.
