Re: [FYI] DAMON and virtio-balloon in DeepSeek's DSec paper

[Gao Xiang <xiang@kernel.org>]

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.
> >