On Mon, Oct 26, 2026 at 01:47:04PM +0100, Gao Xiang wrote: > On Mon, Oct 26, 2026 at 01:35:44PM +0100, Gupta, Pankaj wrote: > > > > > > > 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. > > I know virtio-pmem struct page can be allocated from the device itself. > > But I don't think it changes too much, since guest kernel implementation > shouldn't imply anything of the host. So that the pmem and struct page > can be backed by anonymous memory or other types of memory, and it can > still cause unexpected large amount of memory on the host instead. But > allocating on the device is sightly better than allocate struct page in > the guest. > > The problem is it's hard to make sure the on-demand allocation is always > successful since the guest knows nothing from the host, so that it > exposes security risks like denial-of-service or more. > > If this security concern is not resolved (e.g. implement a reclaim path), > my thought is I think we shouldn't overcommit the struct page since it's > a functional defect if virtio-pmem is reasonably large. >
But I agree that allowing on-demand `struct page` allocation from the device (rather than allocate using the guest memory) has lower risk, maybe allowing this can be the first step to enable on-demand allocation (actually it's not an overcommitting from the guest view since the whole pmem memory range for struct page is reserved). Thanks, Gao Xiang > Thanks, > Gao Xiang > > > > > > 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. > >
