Re: [RFC PATCH] mm/damon: add full LPAE support for memory monitoring above 4GB

[SeongJae Park <sj@kernel.org>]

On Fri, 25 Jul 2025 11:15:22 +0800 zuoze <zuoze1@huawei.com> wrote:

> 
> 
> 在 2025/4/23 1:43, SeongJae Park 写道:
> > On Tue, 22 Apr 2025 19:50:11 +0800 zuoze <zuoze1@huawei.com> wrote:
> > 
> > [...]
> >> Thanks for the patches - I’ve noted the RFC series and user-space
> >> updates. Apologies for the delay; I’ll prioritize reviewing these soon
> >> to verify they meet the intended tracking goals. Appreciate your
> >> patience.
> > 
> > No worry.  Please take your time and let me know if there is anything I can
> > help.
> > 
> > I think we can improve the user-space tool support better for usability.  For
> > example, it could find LPAE case, set addr_unit parameter, and convert
> > user-input and output address ranges on its own.  But hopefully the current
> > support allows simple tests of the kernel side change, and we could do such
> > improvement after the kernel side change is made.
> > 
> > 
> 
> Hi SJ,
> 
> Apologies for the delayed response. We've verified your patch in our
> environment and confirmed it supports LPAE address monitoring.

No worry, thank you for testing that :)

> However,
> we observed some anomalies in the reclaim functionality. During code
> review, we identified a few issues:
> 
> The semantic meaning of damon_region changed after addr_unit was
> introduced. The units in damon_addr_range may no longer represent bytes
> directly.

You're right, and this is an intended change.

> 
> The size returned by damon_sz_region() now requires multiplication by
> addr_unit to get the actual byte count.

Again, this is an intended change.  damon_sz_region() callers should aware this
semantic and updated accordingly, if it could make a real problem otherwise.
If you found such changes required cases that this patch series is missing,
could you please list up?

> 
> Heavy usage of damon_sz_region() and DAMON_MIN_REGION likely requires
> addr_unit-aware adjustments throughout the codebase. While this approach
> works, it would involve considerable changes.

It has been a while since I wrote this patch series, but at least while writing
it, I didn't find such required changes.  Of course I should missed something,
though.  As I mentioned above, could you please list such changes required
parts that makes problem?  That would be helpful at finding the path forward.

> What's your perspective on
> how we should proceed?

Let's see the list of required additional changes with why those are required
(what problems can happen if such chadnges are not made), and discuss.


Thanks,
SJ

[...]