From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: Yunjeong Mun <yunjeong.mun@sk.com>,
honggyu.kim@sk.com, kernel_team@skhynix.com,
Ravi Jonnalagadda <ravis.opensrc@gmail.com>,
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
Subject: Re: [RFC PATCH 0/5] mm/damon: Add node_sys_bp quota goal metric for
Date: Wed, 11 Feb 2026 22:30:09 -0800 [thread overview]
Message-ID: <20260212063009.70556-1-sj@kernel.org> (raw)
In-Reply-To: <20260204060641.97191-1-sj@kernel.org>
On Tue, 3 Feb 2026 22:06:40 -0800 SeongJae Park <sj@kernel.org> wrote:
> On Wed, 4 Feb 2026 11:25:35 +0900 Yunjeong Mun <yunjeong.mun@sk.com> wrote:
>
> > On Fri, Jan 23, 2026 at 05:50:43PM -0800, SeongJae Park wrote:
[...]
> > > IIRC, SK hynix people also confused with the behavior when they experimented
> > > migrate_{hot,cold} action with NODE_MEM_USED_BP goal based quota auto-tuning,
> > > but using only a single scheme that does migration in a single direction.
> > > Because this is at least second time it made confusion, if you need, maybe I
> > > can try to add a feature for making DAMOS immediately stops after the goal is
> > > satisfied. Let me know if such new feature can be useful for you. Cc-ing SK
> > > hynix people (Honggyu and Yunjeong) so that they can correct me if my memory is
> > > broken, or answer if the new feature I described here can be useful for them.
> > >
> >
> > Yes, you're absolutely right. Currently, esz(effective size) starts from 0 and
> > esz gradually increases as `current` approaches `target`.
> > Once `current` reaches `target`, `esz` then begins to decrease.
> >
> > However, we observed that even after `current` hits `target`,
> > migration still continues relatively aggressively - because `esz` remains high,
> > and it takes time for it to decrease.
> >
> > To address this, we previously suggested that initializing `esz` at `target`
> > (or something suitably large value, rather than 0) and letting it gradually
> > decrease as `current` gets closer to `target`.
> > This would allow for stronger migration when `current` is far form `target`,
> > and gradually weaken migration as `current` approaches `target`.
> >
> > Such a feature would be useful for us to experiment with tiered memory system :)
>
> Thank you for confirming, Yunjeong. I now agree this is what really need to be
> implemented. And I agree your suggestion makes sense for the use case. I want
> to take sufficient time for good design of it, though. I will share update as
> soon as I get some idea.
I just posted an RFC patch series for this:
https://lore.kernel.org/20260212062314.69961-1-sj@kernel.org
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-02-12 6:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 4:57 [RFC PATCH 0/5] mm/damon: Add node_sys_bp quota goal metric for PA-based migration control Ravi Jonnalagadda
2026-01-23 4:57 ` [RFC PATCH 1/5] mm/damon/core: add DAMOS_QUOTA_NODE_SYS_BP metric Ravi Jonnalagadda
2026-01-23 4:57 ` [RFC PATCH 2/5] mm/damon: add get_goal_metric() op and PA provider Ravi Jonnalagadda
2026-01-23 4:57 ` [RFC PATCH 3/5] mm/damon/core: add new ops-specific goal metric Ravi Jonnalagadda
2026-01-23 4:57 ` [RFC PATCH 4/5] mm/damon/paddr: capacity clamp and directional early-exit for node_sys_bp Ravi Jonnalagadda
2026-01-23 4:57 ` [RFC PATCH 5/5] mm/damon/sysfs-schemes: accept "node_sys_bp" in goal's target_metric Ravi Jonnalagadda
2026-01-24 1:50 ` [RFC PATCH 0/5] mm/damon: Add node_sys_bp quota goal metric for PA-based migration control SeongJae Park
2026-01-27 18:52 ` Ravi Jonnalagadda
2026-01-28 1:25 ` SeongJae Park
2026-02-12 6:27 ` SeongJae Park
2026-02-04 2:25 ` [RFC PATCH 0/5] mm/damon: Add node_sys_bp quota goal metric for Yunjeong Mun
2026-02-04 6:06 ` SeongJae Park
2026-02-12 6:30 ` 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=20260212063009.70556-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=kernel_team@skhynix.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.