From: Lian Wang <lianux.mm@gmail.com>
To: SJ Park <sj@kernel.org>, Jialiang Huang <huang-jl@deepseek.com>
Cc: lance.yang@linux.dev, KunWu Chan <kunwu.chan@gmail.com>,
baohua@kernel.org, damon@lists.linux.dev, david@kernel.org,
linux-mm@kvack.org, mst@redhat.com, ryncsn@gmail.com,
virtualization@lists.linux.dev, xueyuan.chen21@gmail.com,
xiang@kernel.org
Subject: Re: [FYI] DAMON and virtio-balloon in DeepSeek's DSec paper
Date: Wed, 30 Sep 2026 11:07:29 +0800 [thread overview]
Message-ID: <20260930030747.47294-1-lianux.mm@gmail.com> (raw)
In-Reply-To: <20260929165603.49436-1-sj@kernel.org>
Hi SJ,
On Tue, 29 Sep 2026 09:56:03 -0700 SJ Park <sj@kernel.org> wrote:
> I agree the reclaim-reporting granularity mismatch could be a room to improve.
Thanks for pointing us back to the Access/Contiguity-aware Memory
Autoscaling proposal. Jialiang's description gives us a useful deployment
context and a concrete problem to investigate.
The guest reclaim/reporting case and our host-side THP/tiering case are
different, but both raise questions about how workload behaviour and
monitoring granularity should guide kernel actions.
KunWu and I would like to help move this work forward together, alongside
the existing DAMON roadmap. For now, I would like to share a few possible
areas for discussion:
1. Workloads, DAMON policies, and tiering. My current work includes
improving masim-based experiments and studying TPP-inspired memory
tiering. We would like to make the workloads more representative and
better understand how DAMON's observations and policy settings affect
placement decisions. The aim is to understand where configuration
changes are sufficient and where code changes, if any, would help.
2. Testing and contributing to the existing PMU work. Our initial focus
would be on helping with the Arm SPE integration and testing the IBS
and PEBS work on x86, in coordination with the people already working
on these. The experiments could evaluate whether finer-grained
sampling provides useful additional information, and at what CPU
cost. We could leave huge-page-specific mechanisms for a later
discussion, guided by the results.
3. Following up on the DeepSeek workload. If the team is interested, we
could learn more about the workloads and tuning questions they can
share, and study the path from workload behaviour and monitoring
parameters through reclaim and free-page reporting. Pratyush's
reporting-delay suggestion adds another useful dimension. This may
provide a practical starting point for revisiting parts of the
access/contiguity-aware autoscaling work and evaluating their
relevance to the reported workload.
Could we discuss whether some of these could become follow-up milestones
in the DAMON discussions at LPC, or here on the mailing list? We would be
happy to help organise the discussion and take on agreed pieces of
testing or development. We would also welcome closer collaboration with
DeepSeek and other interested MM developers, including Muchun, where our
work overlaps.
This is only a brief outline for now. I plan to bring the experimental
results and remaining questions to LPC. After discussing and aligning on
the details there, we plan to share a more detailed proposal with the
community and write up the planned work and experimental findings in
blog posts.
I appreciate how much is already on your schedule. We hope to support
the existing plans and help with agreed tasks as the scope becomes
clearer. There is no urgency to reply; we can discuss these ideas
whenever it fits your schedule.
Thanks,
Lian
next prev parent reply other threads:[~2026-09-30 3:08 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
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 [this message]
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=20260930030747.47294-1-lianux.mm@gmail.com \
--to=lianux.mm@gmail.com \
--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=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=ryncsn@gmail.com \
--cc=sj@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=xiang@kernel.org \
--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