linux-kernel - Re: [RFC PATCH -next 11/16] mm/damon: add addr_unit for DAMON_RECLAIM and LRU

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: <20250814161125.67602-1-sj@kernel.org>
Date: Thu, 14 Aug 2025 09:11:25 -0700
From: SeongJae Park <sj@...nel.org>
To: Quanmin Yan <yanquanmin1@...wei.com>
Cc: SeongJae Park <sj@...nel.org>,
	akpm@...ux-foundation.org,
	damon@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	wangkefeng.wang@...wei.com,
	zuoze1@...wei.com
Subject: Re: [RFC PATCH -next 11/16] mm/damon: add addr_unit for DAMON_RECLAIM and LRU_SORT

On Thu, 14 Aug 2025 20:59:04 +0800 Quanmin Yan <yanquanmin1@...wei.com> wrote:

> 
> 在 2025/8/14 0:36, SeongJae Park 写道:
> > On Wed, 13 Aug 2025 13:07:01 +0800 Quanmin Yan <yanquanmin1@...wei.com> wrote:
> >
> >> In module DAMON_RECLAIM and DAMON_LRU_SORT, the damon_ctx is
> >> independent of the core, necessitating dedicated addr_unit
> >> integration for these features.
> >> Additionally, if the input monitor_region_start and monitor_region_end
> >> are both 0 while addr_unit is set to a non-zero valuethe default
> >> system RAM range should be divided by addr_unit.
> > Do you plan to, and need to use DAMON_RECLAIM and DAMON_LRU_SORT on LPAE-ARM32
> > environments?  Can't you use DAMON sysfs interface instead?  If need to use the
> > modules, this change looks good to me in high level.  But if not, I'd like to
> > skip this change, and wait until someone requests it.
> >
> > I'll review the code change in depth after the above question is answered.
> >
> Hi SJ,
> 
> Yes, we need to use these modules in an LPAE-ARM32 environment. The modular
> approach often provides more flexibility in our workflow, so we would greatly
> appreciate it if you could take some time to review the code!🙂

Thank you for clarifying.  Ok, I understand this change is really required.

However, I think reviewing and revising this part may take time.  Meanwhile,
seems this part is not an essential one of this patch series, and has no
problem at be separated and merged after the essential parts.

So, could we separate this part from this patch series?  That is, let's work on
the essential part first.  After the work on the essential part is done, you
could post this part as another patch series, and then we can work together
again on it.


Thanks,
SJ

[...]