DAMON development mailing list
 help / color / mirror / Atom feed
From: Gao Xiang <xiang@kernel.org>
To: Jialiang Huang <huang-jl@deepseek.com>
Cc: lance.yang@linux.dev, baohua@kernel.org, damon@lists.linux.dev,
	david@kernel.org, kunwu.chan@gmail.com, lianux.mm@gmail.com,
	linux-mm@kvack.org, mst@redhat.com, ryncsn@gmail.com,
	sj@kernel.org, virtualization@lists.linux.dev,
	xueyuan.chen21@gmail.com, xiang@kernel.org
Subject: Re: [FYI] DAMON and virtio-balloon in DeepSeek's DSec paper
Date: Tue, 29 Sep 2026 14:41:56 +0200	[thread overview]
Message-ID: <aruyFPzEe3pS_Qzx@XiangdeMacBook-Pro.local> (raw)
In-Reply-To: <20260929123241.1408414-1-huang-jl@deepseek.com>

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.

Thanks,
Gao Xiang

> 
> For disks without virtio-pmem, DAMON with virtio-balloon free-page
> reporting lets us reclaim cold guest page-cache pages and return
> the memory to the host, without those virtio-pmem-specific issues.
> The two approaches complement each other in our setup.
> 
> We have not yet fully explored how best to tune the DAMON and free-page
> reporting parameters for our workloads. For example, the kernel's default
> free-page reporting granularity is 2 MiB, which is fairly coarse:
> reclaiming cold pages does not necessarily produce free blocks of that
> size. We still need to evaluate how finer reporting granularity and
> different DAMON settings affect memory savings and workload performance.
> 
> Best,
> Jialiang Huang

  reply	other threads:[~2026-09-29 12:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25  5:44 [FYI] DAMON and virtio-balloon in DeepSeek's DSec paper Lance Yang
2026-09-25  5:57 ` Lian Wang
2026-09-25  6:46   ` KunWu Chan
2026-09-25  7:04 ` David Hildenbrand (Arm)
2026-09-25  7:28   ` Lian Wang
2026-09-25  8:15   ` Lance Yang
2026-09-25 10:03     ` David Hildenbrand (Arm)
2026-09-25 10:16     ` Gao Xiang
2026-09-25 10:27       ` Gao Xiang
2026-09-25 10:13 ` SJ Park
2026-09-29 12:32 ` Jialiang Huang
2026-09-29 12:41   ` Gao Xiang [this message]
2026-09-29 12:50     ` Jialiang Huang
2026-09-30  3:36     ` Muchun Song
2026-09-30  7:24       ` Gao Xiang
2026-09-30  9:37         ` Muchun Song
2026-09-30 10:33           ` Gao Xiang
2026-09-29 16:56   ` SJ Park
2026-09-30  3:07     ` Lian Wang
2026-09-30  8:08       ` SJ Park
2026-09-29 18:14   ` Pratyush Mallick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aruyFPzEe3pS_Qzx@XiangdeMacBook-Pro.local \
    --to=xiang@kernel.org \
    --cc=baohua@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=david@kernel.org \
    --cc=huang-jl@deepseek.com \
    --cc=kunwu.chan@gmail.com \
    --cc=lance.yang@linux.dev \
    --cc=lianux.mm@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=ryncsn@gmail.com \
    --cc=sj@kernel.org \
    --cc=virtualization@lists.linux.dev \
    --cc=xueyuan.chen21@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox