From: SeongJae Park <sj@kernel.org>
To: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
akpm@linux-foundation.org, corbet@lwn.net, bijan311@gmail.com,
ajayjoshi@micron.com, honggyu.kim@sk.com, yunjeong.mun@sk.com
Subject: Re: [RFC PATCH v2 0/3] mm/damon: Introduce node_target_mem_bp Quota Goal Metric
Date: Tue, 3 Feb 2026 16:28:58 -0800 [thread overview]
Message-ID: <20260204002900.49291-1-sj@kernel.org> (raw)
In-Reply-To: <CALa+Y1475VSnrNTn-AQtTTnye+sdAGu9sVO0YMEtLidNW53_=A@mail.gmail.com>
On Tue, 3 Feb 2026 11:48:06 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> On Sat, Jan 31, 2026 at 11:54 AM SeongJae Park <sj@kernel.org> wrote:
> >
> > On Thu, 29 Jan 2026 17:48:06 -0800 SeongJae Park <sj@kernel.org> wrote:
> >
> > > On Thu, 29 Jan 2026 13:58:11 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> > >
> > > > This series introduces a new DAMON quota goal metric, `node_target_mem_bp`,
> > > > designed for controlling memory migration in heterogeneous memory systems
> > > > (e.g., DRAM and CXL memory tiering).
> > > >
> > > > v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u
> > [...]
> > > Context 0: monitors node 0, migrate_hot -> node 1
> > > goal: node_ineligible_mem_bp, nid=0, target=4000
> > >
> > > Context 1: monitors node 1, migrate_hot -> node 0
> > > goal: node_target_mem_bp, nid=0, target=6000
> >
> > In offline, Ravi enlightened me that using a single context with two schemes
> > instead of the above two contexts setup can be more efficienct and useful. I
> > agree that. It will be able to only single kdamond, and there could be more
> > flexible use cases that can use the whole-memory access pattern.
> >
> > That is, we can use single context with the two schemes, but adding a core
> > layer DAMOS filters for applying the schemes to only memory of node 0 and node
> > 1, respectively. Similar for memory tiering use cases.
> >
> > But I was recommending the multi contexts approach to people because the
> > current implementation of DAMOS is not efficient when both quota and core layer
> > filters are used. I was actually working on making it improved, and just
> > posted an RFC patch series [1]. After the patches are merged, hopefully the
> > single context approach will be useful and effcient enough for varying use
> > cases including the memory tiering.
> >
> > [1] https://lore.kernel.org/20260131194145.66286-1-sj@kernel.org
> >
> Thanks for providing the DAMOS_FILTER patch update SJ.
>
> For v3, I plan to introduce two complementary metrics:
> DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP
> and DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP.
>
> This will support the following approaches for hot memory migration:
> 1. Single context with two schemes using both metrics.
> (along with DAMOS_FILTER_TYPE_ADDR)
> 2. Two DAMON contexts each using
> DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP.
Sounds good!
>
> Will provide more details on the implementation and usage in the v3 series.
Looking forward to it!
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-02-04 0:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-29 21:58 [RFC PATCH v2 0/3] mm/damon: Introduce node_target_mem_bp Quota Goal Metric Ravi Jonnalagadda
2026-01-29 21:58 ` [PATCH 1/3] mm/damon/core: add DAMOS_QUOTA_NODE_TARGET_MEM_BP metric Ravi Jonnalagadda
2026-01-30 1:49 ` SeongJae Park
2026-01-29 21:58 ` [PATCH 2/3] mm/damon/core: implement NODE_TARGET_MEM_BP metric calculation Ravi Jonnalagadda
2026-01-29 21:58 ` [PATCH 3/3] mm/damon/sysfs-schemes: expose NODE_TARGET_MEM_BP metric Ravi Jonnalagadda
2026-01-30 1:48 ` [RFC PATCH v2 0/3] mm/damon: Introduce node_target_mem_bp Quota Goal Metric SeongJae Park
2026-01-31 19:54 ` SeongJae Park
2026-02-03 19:48 ` Ravi Jonnalagadda
2026-02-04 0:28 ` SeongJae Park [this message]
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=20260204002900.49291-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=ajayjoshi@micron.com \
--cc=akpm@linux-foundation.org \
--cc=bijan311@gmail.com \
--cc=corbet@lwn.net \
--cc=damon@lists.linux.dev \
--cc=honggyu.kim@sk.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ravis.opensrc@gmail.com \
--cc=yunjeong.mun@sk.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.