Previously, DAMON's physical address space monitoring only supported
memory ranges below 4GB on LPAE-enabled systems. This was due to
the use of 'unsigned long' in 'struct damon_addr_range', which is
32-bit on ARM32 even with LPAE enabled.

Implements DAMON compatibility for ARM32 with LPAE enabled.

Patches 01/16 through 10/16 are from the mailing list[1], add a new core
layer parameter called 'addr_unit'. Operations set layer can translate a
core layer address to the real address by multiplying the parameter value
to the core layer address.

Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
various issues introduced by the addr_unit implementation.

Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.

[1] https://lore.kernel.org/all/20250416042551.158131-1-sj@kernel.org/

Quanmin Yan (6):
  mm/damon: add addr_unit for DAMON_RECLAIM and LRU_SORT
  mm/damon: add damon_ctx->min_region and damon_target->min_region
  mm/damon/sysfs: ensure valid addr_unit setting in
    damon_sysfs_apply_inputs()
  mm/damon/core: convert sz to byte units when updating state
  mm/damon: the byte statistics data type in damos_stat uses unsigned
    long long
  mm/damon/core: handle quota->esz overflow issues

SeongJae Park (10):
  mm/damon/core: add damon_ctx->addr_unit
  mm/damon/paddr: support addr_unit for access monitoring
  mm/damon/paddr: support addr_unit for DAMOS_PAGEOUT
  mm/damon/paddr: support addr_unit for DAMOS_LRU_[DE]PRIO
  mm/damon/paddr: support addr_unit for MIGRATE_{HOT,COLD}
  mm/damon/paddr: support addr_unit for DAMOS_STAT
  mm/damon/sysfs: implement addr_unit file under context dir
  Docs/mm/damon/design: document 'address unit' parameter
  Docs/admin-guide/mm/damon/usage: document addr_unit file
  Docs/ABI/damon: document addr_unit file

 .../ABI/testing/sysfs-kernel-mm-damon         |  7 ++
 Documentation/admin-guide/mm/damon/usage.rst  | 11 ++-
 Documentation/mm/damon/design.rst             | 16 +++-
 include/linux/damon.h                         | 24 +++--
 mm/damon/core.c                               | 80 +++++++++++-----
 mm/damon/lru_sort.c                           | 16 +++-
 mm/damon/modules-common.c                     |  5 +-
 mm/damon/modules-common.h                     |  6 +-
 mm/damon/paddr.c                              | 95 ++++++++++++-------
 mm/damon/reclaim.c                            | 16 +++-
 mm/damon/stat.c                               |  2 +-
 mm/damon/sysfs-schemes.c                      | 12 +--
 mm/damon/sysfs.c                              | 27 ++++++
 13 files changed, 226 insertions(+), 91 deletions(-)

-- 
2.34.1

Hello Quanmin,

On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:

> Previously, DAMON's physical address space monitoring only supported
> memory ranges below 4GB on LPAE-enabled systems. This was due to
> the use of 'unsigned long' in 'struct damon_addr_range', which is
> 32-bit on ARM32 even with LPAE enabled.
> 
> Implements DAMON compatibility for ARM32 with LPAE enabled.

Thank you for working on this, Quanmin!

> 
> Patches 01/16 through 10/16 are from the mailing list[1], add a new core
> layer parameter called 'addr_unit'. Operations set layer can translate a
> core layer address to the real address by multiplying the parameter value
> to the core layer address.
> 
> Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
> various issues introduced by the addr_unit implementation.
> 
> Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.

Overall, looks good to me.  I have a few change requests including below major
ones, though.

First, let's squash patches for fixing problems made with patches 1-10 into
patches 1-10.  If you don't mind, I will post RFC v2 of those so that you can
pick into your series.

Second, let's keep DAMOS stats in 'unsigned long' type.  This require fixups of
patches 1-10.  If you don't mind, I will also do this in RFC v2 of those.

Please let me know what do you think.

I left a few more comments to patches, let's discuss on the replies.


Thanks,
SJ

[...]

On Wed, 13 Aug 2025 10:25:44 -0700 SeongJae Park <sj@kernel.org> wrote:

> Hello Quanmin,
> 
> On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:
> 
> > Previously, DAMON's physical address space monitoring only supported
> > memory ranges below 4GB on LPAE-enabled systems. This was due to
> > the use of 'unsigned long' in 'struct damon_addr_range', which is
> > 32-bit on ARM32 even with LPAE enabled.
> > 
> > Implements DAMON compatibility for ARM32 with LPAE enabled.
> 
> Thank you for working on this, Quanmin!
> 
> > 
> > Patches 01/16 through 10/16 are from the mailing list[1], add a new core
> > layer parameter called 'addr_unit'. Operations set layer can translate a
> > core layer address to the real address by multiplying the parameter value
> > to the core layer address.
> > 
> > Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
> > various issues introduced by the addr_unit implementation.
> > 
> > Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.
> 
> Overall, looks good to me.  I have a few change requests including below major
> ones, though.
> 
> First, let's squash patches for fixing problems made with patches 1-10 into
> patches 1-10.  If you don't mind, I will post RFC v2 of those so that you can
> pick into your series.
> 
> Second, let's keep DAMOS stats in 'unsigned long' type.  This require fixups of
> patches 1-10.  If you don't mind, I will also do this in RFC v2 of those.

Instead of posting completely new RFC v2 of the ten patches, I think posting
fixup patches as replies to this thread might be a better approach.  I will
make fixups first, see what looks easier for working together with you, and
either post entirely new version of the patch series, or send individual fixups
as replies to each patch of this thread.

And one more questions.  What is the baseline if this series?  I cannot simply
apply these patches on mm-unstable or mm-new.  It would be nice if you could
share a git tree having these patches fully applied, since 'cherry-pick' is
easier than 'am' for me.


Thanks,
SJ

[...]

在 2025/8/14 8:57, SeongJae Park 写道:
> On Wed, 13 Aug 2025 10:25:44 -0700 SeongJae Park <sj@kernel.org> wrote:
>
>> Hello Quanmin,
>>
>> On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:
>>
>>> Previously, DAMON's physical address space monitoring only supported
>>> memory ranges below 4GB on LPAE-enabled systems. This was due to
>>> the use of 'unsigned long' in 'struct damon_addr_range', which is
>>> 32-bit on ARM32 even with LPAE enabled.
>>>
>>> Implements DAMON compatibility for ARM32 with LPAE enabled.
>> Thank you for working on this, Quanmin!
>>
>>> Patches 01/16 through 10/16 are from the mailing list[1], add a new core
>>> layer parameter called 'addr_unit'. Operations set layer can translate a
>>> core layer address to the real address by multiplying the parameter value
>>> to the core layer address.
>>>
>>> Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
>>> various issues introduced by the addr_unit implementation.
>>>
>>> Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.
>> Overall, looks good to me.  I have a few change requests including below major
>> ones, though.
>>
>> First, let's squash patches for fixing problems made with patches 1-10 into
>> patches 1-10.  If you don't mind, I will post RFC v2 of those so that you can
>> pick into your series.
>>
>> Second, let's keep DAMOS stats in 'unsigned long' type.  This require fixups of
>> patches 1-10.  If you don't mind, I will also do this in RFC v2 of those.
> Instead of posting completely new RFC v2 of the ten patches, I think posting
> fixup patches as replies to this thread might be a better approach.  I will
> make fixups first, see what looks easier for working together with you, and
> either post entirely new version of the patch series, or send individual fixups
> as replies to each patch of this thread.
>
> And one more questions.  What is the baseline if this series?  I cannot simply
> apply these patches on mm-unstable or mm-new.  It would be nice if you could
> share a git tree having these patches fully applied, since 'cherry-pick' is
> easier than 'am' for me.

Hi SJ,

Thank you for your detailed suggestions on the patch series. Please allow me
some time to thoroughly review each of your recommendations. I haven’t responded
to every point immediately because I’d like to first attempt updating the patches
accordingly. If I encounter any questions or issues during the process, I’ll promptly
reach out to discuss them with you, very appreciate your patience and guidance.

By the way, this patch series is based on linux-next(commit:2674d1eadaa2).

Thanks,
Quanmin Yan

>
> Thanks,
> SJ
>
> [...]
>

On Thu, 14 Aug 2025 22:07:12 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:

> 
> 在 2025/8/14 8:57, SeongJae Park 写道:
> > On Wed, 13 Aug 2025 10:25:44 -0700 SeongJae Park <sj@kernel.org> wrote:
> >
> >> Hello Quanmin,
> >>
> >> On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:
> >>
> >>> Previously, DAMON's physical address space monitoring only supported
> >>> memory ranges below 4GB on LPAE-enabled systems. This was due to
> >>> the use of 'unsigned long' in 'struct damon_addr_range', which is
> >>> 32-bit on ARM32 even with LPAE enabled.
> >>>
> >>> Implements DAMON compatibility for ARM32 with LPAE enabled.
> >> Thank you for working on this, Quanmin!
> >>
> >>> Patches 01/16 through 10/16 are from the mailing list[1], add a new core
> >>> layer parameter called 'addr_unit'. Operations set layer can translate a
> >>> core layer address to the real address by multiplying the parameter value
> >>> to the core layer address.
> >>>
> >>> Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
> >>> various issues introduced by the addr_unit implementation.
> >>>
> >>> Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.
> >> Overall, looks good to me.  I have a few change requests including below major
> >> ones, though.
> >>
> >> First, let's squash patches for fixing problems made with patches 1-10 into
> >> patches 1-10.  If you don't mind, I will post RFC v2 of those so that you can
> >> pick into your series.
> >>
> >> Second, let's keep DAMOS stats in 'unsigned long' type.  This require fixups of
> >> patches 1-10.  If you don't mind, I will also do this in RFC v2 of those.
> > Instead of posting completely new RFC v2 of the ten patches, I think posting
> > fixup patches as replies to this thread might be a better approach.  I will
> > make fixups first, see what looks easier for working together with you, and
> > either post entirely new version of the patch series, or send individual fixups
> > as replies to each patch of this thread.
> >
> > And one more questions.  What is the baseline if this series?  I cannot simply
> > apply these patches on mm-unstable or mm-new.  It would be nice if you could
> > share a git tree having these patches fully applied, since 'cherry-pick' is
> > easier than 'am' for me.
> 
> Hi SJ,
> 
> Thank you for your detailed suggestions on the patch series. Please allow me
> some time to thoroughly review each of your recommendations.

No worry, please take your time :)

> I haven’t responded
> to every point immediately because I’d like to first attempt updating the patches
> accordingly. If I encounter any questions or issues during the process, I’ll promptly
> reach out to discuss them with you, very appreciate your patience and guidance.

Sounds good.

> 
> By the way, this patch series is based on linux-next(commit:2674d1eadaa2).

Thank you for sharing this.  From the next time, please use mm-new[1] as a
baseline for DAMON patches if there is no reason to not do so.

[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees


Thanks,
SJ

[...]

Hi SJ,

在 2025/8/15 0:04, SeongJae Park 写道:
> On Thu, 14 Aug 2025 22:07:12 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:
>
>> Hi SJ,
>>
>> Thank you for your detailed suggestions on the patch series. Please allow me
>> some time to thoroughly review each of your recommendations.
> No worry, please take your time :)
>
>> I haven’t responded
>> to every point immediately because I’d like to first attempt updating the patches
>> accordingly. If I encounter any questions or issues during the process, I’ll promptly
>> reach out to discuss them with you, very appreciate your patience and guidance.
> Sounds good.
>
>> By the way, this patch series is based on linux-next(commit:2674d1eadaa2).
> Thank you for sharing this.  From the next time, please use mm-new[1] as a
> baseline for DAMON patches if there is no reason to not do so.
>
> [1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees

I've prepared the v2 patch set based on the mm-new branch[1]. Your valuable
feedback would be greatly appreciated!

[1] https://lore.kernel.org/all/20250820080623.3799131-1-yanquanmin1@huawei.com/

Thanks,
Quanmin Yan

On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:

> Previously, DAMON's physical address space monitoring only supported
> memory ranges below 4GB on LPAE-enabled systems. This was due to
> the use of 'unsigned long' in 'struct damon_addr_range', which is
> 32-bit on ARM32 even with LPAE enabled.
> 
> Implements DAMON compatibility for ARM32 with LPAE enabled.
> 
> Patches 01/16 through 10/16 are from the mailing list[1], add a new core
> layer parameter called 'addr_unit'. Operations set layer can translate a
> core layer address to the real address by multiplying the parameter value
> to the core layer address.
> 
> Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
> various issues introduced by the addr_unit implementation.
> 
> Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.
> 
> [1] https://lore.kernel.org/all/20250416042551.158131-1-sj@kernel.org/

It would be nice to add more history about this nice work here, with links.


Thanks,
SJ

[...]