From: SJ Park <sj@kernel.org>
To: Lian Wang <lianux.mm@gmail.com>
Cc: SJ Park <sj@kernel.org>, Jialiang Huang <huang-jl@deepseek.com>,
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 01:08:38 -0700 [thread overview]
Message-ID: <20260930080838.10887-1-sj@kernel.org> (raw)
In-Reply-To: <20260930030747.47294-1-lianux.mm@gmail.com>
Hi Lian,
On Wed, 30 Sep 2026 11:07:29 +0800 Lian Wang <lianux.mm@gmail.com> wrote:
> 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?
Thank you for adding topics to discuss.
Of course we could disucss anywhere anytime. I think Access/Contituity-aware
Memory Autoscaling (ACMA) could be just a parallel project. It doens't need to
be an extension of, or blocked by "beyond-page table access bit" project, in my
humble opinion.
ACMA is still on my TODO list. It is mainly a matter of prioritization. As it
becomes clear it requires more attention, I could allocate more time for the
project. There was a user showing interest recently. I'm planning to
prioritize it more. If DeepSeek could confirm their interest, it could help me
prioritizing it further.
As always, coding may not be that difficult and take that long time. Testing
might be the biggest challenge. I don't have good test infrastructure now.
Actually the lack of good test infrastructure is one of my biggest DAMON
maintenance concerns nowadays. Others' help on testing or test infra would be
super helpful.
If someone wants to implement and contribute it based on the proposed idea, it
would also be nice.
> 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.
Sounds great. That would be super productive collaborations.
>
> 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.
We could keep discussing in mailing list, but of course in person discussions
are always helpful. I'm eagerly looking forward to the next week :)
>
> 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.
Appreciate your continued and grateful contributions, Lian.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-09-30 8: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
2026-09-30 8:08 ` SJ Park [this message]
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=20260930080838.10887-1-sj@kernel.org \
--to=sj@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=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