linux-kernel - Re: [RFC PATCH 0/5] mm/damon: Add node_sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260204060641.97191-1-sj@kernel.org>
Date: Tue,  3 Feb 2026 22:06:40 -0800
From: SeongJae Park <sj@...nel.org>
To: Yunjeong Mun <yunjeong.mun@...com>
Cc: SeongJae Park <sj@...nel.org>,
	honggyu.kim@...com,
	kernel_team@...ynix.com,
	Ravi Jonnalagadda <ravis.opensrc@...il.com>,
	damon@...ts.linux.dev,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org,
	akpm@...ux-foundation.org,
	corbet@....net,
	bijan311@...il.com,
	ajayjoshi@...ron.com
Subject: Re: [RFC PATCH 0/5] mm/damon: Add node_sys_bp quota goal metric for

On Wed,  4 Feb 2026 11:25:35 +0900 Yunjeong Mun <yunjeong.mun@...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

[...]