Re: [PATCH] mm/damon: unify address range representation with damon_addr_range

[SeongJae Park <sj@kernel.org>]

Hello Quanmin,

On Fri, 30 Jan 2026 11:07:08 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:

Thank you for jumping in and giving great comments!

> 在 2026/1/30 10:26, Quanmin Yan 写道:
> > Hi SJ,
> >
> > [...]
> >
> >> Actually, there is another bug that need to be fixed.  Nonetheless, 
> >> that's
> >> orthogonal to this patch, so it is not a blocker of this patch in my 
> >> opinion.
> >
> > Are you referring to the scenario where, on a 32-bit system with LPAE 
> > support, the biggest System RAM address found exceeds the range of 
> > unsigned long? Actually, DAMON only actively searches for the biggest 
> > System RAM address when the user does not set a monitoring region. In 
> > this case, we always reset addr_unit to 1, which essentially restricts 
> > DAMON’s monitorable address range to 0–UL. Therefore, the described 
> > situation does not occur. For details, please refer to commit [1]. 
> > However, we could perhaps further optimize this by finding any biggest 
> > System RAM address, setting damon_addr_range, and dynamically 
> > adjusting addr_unit. However, there are currently no specific 
> > requirements for this, so this work has been temporarily put on hold. 
> > [1] commit dfc02531f413 ("mm/damon/reclaim: use min_sz_region for core 
> > address alignment when setting regions") Thanks, Quanmin Yan
> >
> > [...] 
> 
> (Sorry there was an issue with my email client. I am resending now.)

No worry!

> 
> Are you referring to the scenario where, on a 32-bit system with LPAE
> support, the biggest System RAM address found exceeds the range of
> unsigned long?

You are right.

> 
> Actually, DAMON only actively searches for the biggest System RAM
> address when the user does not set a monitoring region. In this case,
> we always reset addr_unit to 1, which essentially restricts DAMON’s
> monitorable address range to 0–UL. Therefore, the described situation
> does not occur. For details, please refer to commit [1].

Again, you are correct.  There is no user scenario that can trigger the
problematic situation in the real world.  Nevertheless, assigning
'resource_size_t' value to 'unsigned long' storage makes no sense, so I'm
calling such things a bug.  Not impacting user world, but still a bug is a bug.
In my opinion, all bugs are better to be fixed unless it makes maintenance
overhead increased too much.  Also, who knows if I will introduce another code
calling it with >1 add_unit.

> 
> However, we could perhaps further optimize this by finding any biggest
> System RAM address, setting damon_addr_range, and dynamically adjusting
> addr_unit.

I agree.  I think we can fix the function first, and later consider further
allowing users to use its full power.

> However, there are currently no specific requirements for
> this, so this work has been temporarily put on hold.

You are right.  As long as there is no requirements, there is no reason to
expose the full power to users at the moment.

By the way, one thing that may better to be clear is that I requested you to
make the implementation in this way.  Nobody should be blamed, but if someone
has to be blamed for the current shape of the code, it is only me. :)

> 
> [1] commit dfc02531f413 ("mm/damon/reclaim: use min_sz_region for core
> address alignment when setting regions")


Thanks,
SJ

[...]