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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250703010341.58007-1-sj@kernel.org>
Date: Wed,  2 Jul 2025 18:03:41 -0700
From: SeongJae Park <sj@...nel.org>
To: Bijan Tabatabai <bijan311@...il.com>
Cc: SeongJae Park <sj@...nel.org>,
	damon@...ts.linux.dev,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org,
	akpm@...ux-foundation.org,
	corbet@....net,
	joshua.hahnjy@...il.com,
	bijantabatab@...ron.com,
	venkataravis@...ron.com,
	emirakhur@...ron.com,
	ajayjoshi@...ron.com,
	vtavarespetr@...ron.com
Subject: Re: [RFC PATCH v3 00/13] mm/damon/vaddr: Allow interleaving in migrate_{hot,cold} actions

Hello Bijan,

On Wed,  2 Jul 2025 15:13:23 -0500 Bijan Tabatabai <bijan311@...il.com> wrote:

> From: Bijan Tabatabai <bijantabatab@...ron.com>
> 
> A recent patch set automatically sets the interleave weight for each node
> according to the node's maximum bandwidth [1]. In another thread, the patch
> set's author, Joshua Hahn, wondered if/how thes weights should be changed
> if the bandwidth utilization of the system changes [2].
> 
> This patch set adds the mechanism for dynamically changing how application
> data is interleaved across nodes while leaving the policy of what the
> interleave weights should be to userspace. It does this by having the
> migrate_{hot,cold} operating schemes interleave application data according
> to the list of migration nodes and weights passed in via the DAMON sysfs
> interface. This functionality can be used to dynamically adjust how folios
> are interleaved by having a userspace process adjust those weights. If no
> specific destination nodes or weights are provided, the migrate_{hot,cold}
> actions will only migrate folios to damos->target_nid as before.
[...]
> Functionality Test
> ==================
> Below is an example of this new functionality in use to confirm that these
> patches behave as intended.
> In this example, the user starts an application, alloc_data, which
> allocates 1GB using the default memory policy (i.e. allocate to local
> memory) then sleeps. Afterwards, we start DAMON to interleave the data at a
> 1:1 ratio. Using numastat, we show that DAMON has migrated the
> application's data to match the new interleave ratio.
> For this example, I modified the userspace damo tool [8] to write to the
> migration_dest sysfs files. I plan to upstream these changes when these
> patches are merged.

Looking forward to!

[...]
> Performance Test
> ================
[...]
> Updating the interleave weights and having DAMON migrate the workload data
> according to the weights resulted in an approximarely 25% speedup.

Nice!

[...]
> Revision History
> ================
> Changes from v2 [9]:
> - Implement interleaving using vaddr instead of paddr
> - Add vaddr implementation of migrate_{hot,cold}
> - Use DAMON specific interleave weights instead of mempolicy weights

Appreciate your efforts on revisioning!

I left a few comments including simple change requests and questions as replies
to each patch.  In high level, looks good to me.

[...]
> P.S., I will be out of office Thursday until next week Tuesday, so please
> forgive any delayed responses.

No worry, please take your time and fun! :)


Thanks,
SJ

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ