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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260204022537.814-1-yunjeong.mun@sk.com>
Date: Wed,  4 Feb 2026 11:25:35 +0900
From: Yunjeong Mun <yunjeong.mun@...com>
To: sj@...nel.org
Cc: 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 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 :)

Best Regards,
Yunjeong