On Wed, 13 Aug 2025 10:25:44 -0700 SeongJae Park <sj@xxxxxxxxxx> wrote:
Hello Quanmin,Instead of posting completely new RFC v2 of the ten patches, I think posting
On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@xxxxxxxxxx> wrote:
Previously, DAMON's physical address space monitoring only supportedThank you for working on this, Quanmin!
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 coreOverall, looks good to me. I have a few change requests including below major
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.
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.
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
[...]