From: Gao Xiang <xiang@kernel.org>
To: Muchun Song <muchun.song@linux.dev>
Cc: Gao Xiang <xiang@kernel.org>,
Jialiang Huang <huang-jl@deepseek.com>,
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, Matthew Wilcox <willy@infradead.org>
Subject: Re: [FYI] DAMON and virtio-balloon in DeepSeek's DSec paper
Date: Wed, 30 Sep 2026 12:33:33 +0200 [thread overview]
Message-ID: <arzlfSOgtC-CLoZt@MacBookPro> (raw)
In-Reply-To: <CEE47F27-874B-486A-995F-E223249659FE@linux.dev>
On Wed, Sep 30, 2026 at 05:37:11PM +0800, Muchun Song 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.
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.
Thanks,
Gao Xiang
>
> Thanks,
> Muchun
>
> >
> > Thanks,
> > Gao Xiang
>
>
next prev parent reply other threads:[~2026-09-30 10:33 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 [this message]
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=arzlfSOgtC-CLoZt@MacBookPro \
--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=muchun.song@linux.dev \
--cc=ryncsn@gmail.com \
--cc=sj@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=willy@infradead.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