All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Yunjeong Mun <yunjeong.mun@sk.com>
Cc: SeongJae Park <sj@kernel.org>,
	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: Tue,  3 Feb 2026 22:06:40 -0800	[thread overview]
Message-ID: <20260204060641.97191-1-sj@kernel.org> (raw)
In-Reply-To: <20260204022537.814-1-yunjeong.mun@sk.com>

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:
> > Cc-ing SK hynix folks (Honggyu and Yunjeong) for quota auto-tuning behavior
> > confusion (not stop immediately after satisfying the goal) I discuss below.
> > 
> 
> Hi Seonjae, thanks for Cc-ing us :)
> 
> > 
> > Please note that the goal-based quota auto-tuning works in proportional way,
> > preferring small steps and "eventual" goal convergence.  As a result, migration
> > will occur a few more times until it is completely stopped after the goal is
> > satisfied.  Unless there is another scheme that migrates pages into node 0, you
> > may end up having node 0 having a bit less than the 40% memory.
> > 
> > > 
> > >     No oscillation - migration stops when target state is reached.
> > 
> > So, little bit of oscillation could still happen.  Hopefully that shouldn't be
> > significant, though.
> > 
> > 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.


Thanks,
SJ

[...]

  reply	other threads:[~2026-02-04  6:06 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 [this message]
2026-02-12  6:30       ` SeongJae Park

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=20260204060641.97191-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.