From: SeongJae Park <sj@kernel.org>
To: Ze Zuo <zuoze1@huawei.com>
Cc: SeongJae Park <sj@kernel.org>,
akpm@linux-foundation.org, damon@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
wangkefeng.wang@huawei.com
Subject: Re: [RFC PATCH] mm/damon: add full LPAE support for memory monitoring above 4GB
Date: Tue, 8 Apr 2025 19:50:36 -0700 [thread overview]
Message-ID: <20250409025036.70633-1-sj@kernel.org> (raw)
In-Reply-To: <20250408075553.959388-1-zuoze1@huawei.com>
Hi Ze,
On Tue, 8 Apr 2025 15:55:53 +0800 Ze Zuo <zuoze1@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.
Nice finding!
>
> This patch modifies the data types to properly support >4GB physical
> address spaces:
> 1. Changes 'start' and 'end' in 'struct damon_addr_range' from
> 'unsigned long' to 'unsigned long long' (u64)
> 2. Updates all related arithmetic operations and comparisons
> 3. Adjusts print formats from %lu to %llu where needed
> 4. Maintains backward compatibility for non-LPAE systems
>
> Since the overhead of always using u64 is negligible on 32-bit systems,
> should we prefer this simplified approach over the conditional typedef?
>
> Alternative implementation approaches to consider:
>
> 1. Introduce damon_addr_t that adapts to CONFIG_PHYS_ADDR_T_64BIT
> 2. Convert all DAMON address operations to use this type
>
> Just like implementation:
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> typedef unsigned long long damon_addr_t;
> #else
> typedef unsigned long damon_addr_t;
> #endif
>
> This method could potentially cause minor issues with print formatting
> and division operations. We'd appreciate any suggestions for better
> approaches. Thank you for your input.
>
> The patch change allows DAMON to work with:
> - 32-bit ARM with LPAE (40-bit physical addresses)
> - 64-bit ARM systems
> - x86_64 physical address monitoring
> while preserving existing behavior on 32-bit systems without LPAE.
Again, nice finding and good improvement. Thank you so much for sharing this
nice patch.
But, this doesn't seem like a very small and simple change. I think we can
find the best approach together, by understanding impact of this change for
short term and long term. For that, could you please also share how prevalent
32-bit ARM machines with LPAE are, and what would be your expected usage of
physical address space monitoring on such machines, in both short term and long
term?
Thanks,
SJ
[...]
next prev parent reply other threads:[~2025-04-09 2:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 7:55 [RFC PATCH] mm/damon: add full LPAE support for memory monitoring above 4GB Ze Zuo
2025-04-09 2:50 ` SeongJae Park [this message]
2025-04-09 7:01 ` zuoze
2025-04-09 17:36 ` SeongJae Park
2025-04-10 6:28 ` zuoze
2025-04-10 22:25 ` SeongJae Park
2025-04-11 6:30 ` zuoze
2025-04-11 16:35 ` SeongJae Park
2025-04-14 1:21 ` zuoze
2025-04-20 16:27 ` SeongJae Park
2025-04-22 11:50 ` zuoze
2025-04-22 17:43 ` SeongJae Park
2025-07-25 3:15 ` zuoze
2025-07-25 20:22 ` SeongJae Park
2025-07-26 3:14 ` Quanmin Yan
2025-07-26 17:16 ` SeongJae Park
2025-07-29 13:52 ` Quanmin Yan
2025-07-29 15:53 ` SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250409025036.70633-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wangkefeng.wang@huawei.com \
--cc=zuoze1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.