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

[Gao Xiang <xiang@kernel.org>]

On Wed, Sep 30, 2026 at 11:36:23AM +0800, Muchun Song wrote:
> 
> 
> > On Sep 29, 2026, at 20:41, Gao Xiang <xiang@kernel.org> wrote:
> > 
> > On Tue, Sep 29, 2026 at 08:32:41PM +0800, Jialiang Huang wrote:
> >> Hi all,
> >> 
> >> I'm an engineer at DeepSeek. Thanks for the discussion, and thanks
> >> to everyone working on DAMON and virtio-balloon free-page reporting.
> >> They have been very useful for our workloads.
> >> 
> >> Gao Xiang wrote:
> >>> It can cause sync 4K faults on the host in the worst case
> >> 
> >> This is one of our concerns with virtio-pmem as well: moving I/O onto
> >> the page-fault path can introduce performance trade-offs. The other
> >> concern is the substantial struct page overhead for large images.
> >> 
> >> For now, we enable virtio-pmem only for moderately sized, frequently
> >> used read-only images, where there is more opportunity to share the
> >> same host page cache across sandboxes, as Gao pointed out.
> >> 
> >> Muchun's vmemmap work is also interesting to us. My understanding is
> >> that it allocates private backing for struct page metadata on demand,
> >> which could help reduce the upfront memory overhead for large images.
> > 
> > Although I haven't had a chance and time to look into that, the main
> > concern from me is that mmap() access will call
> > "dax_fault_iter->vmemmap_materialize_page()", and malicious sandbox
> > workloads (or not malicious, just valid mmap workloads) can cause guest
> > memory OOMs due to "struct page balloon" for large rootfs in the worst
> > cases and cause the follow-up mmap access failure, because the guest
> > memory size may not even fulfill "struct page" for large rootfs.
> 
> I agree that this is a real issue with v1.
> 
> One detail is that merely establishing the mapping does not materialize
> the metadata. Materialization happens when a fault resolves to an
> allocated DAX extent, before its PFN is inserted into a userspace
> mapping. However, that distinction does not remove the problem.
> 
> In the worst case, a workload can fault enough of the pmem range to
> restore the full vmemmap cost, about 1.56% of the pmem size. Since v1
> does not dematerialize private vmemmap pages, even a one-time scan can
> retain that cost until the device is removed.
> 
> The follow-up mentioned in the cover letter is intended to make the
> optimization reversible. One possible direction would be to invalidate
> clean DAX entries under memory pressure and zap their userspace
> mappings. Once a DAX entry has been removed and the corresponding PFNs
> have no remaining mappings, references, or pins that require private
> metadata, the associated vmemmap backing could be remapped to the
> shared read-only page. A later access would fault and materialize it
> again.

BTW, it's impossible for shared DAX entries (like the current XFS DAX
with reflink and EROFS will support this feature later too for chunk
memory sharing), since you cannot just use mapping and index to get
the VMA like page cache does unless you invent another new mechanism
for this.

Reclaiming page entry mechanism seems it can be used for or overlapped
to another types of memory (in order to save struct page memory in
general): I'm not sure if it needs wider discussion on reclaiming
"struct page" in general first.

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.

Thanks,
Gao Xiang