Re: [PATCH v2 03/11] mm/damon/paddr: support addr_unit for DAMOS_PAGEOUT

[Quanmin Yan]

在 2025/8/26 22:21, SeongJae Park 写道:
> On Tue, 26 Aug 2025 12:51:17 +0800 Quanmin Yan <yanquanmin1@xxxxxxxxxx> wrote:
>
> > Hi SJ,
> >
> > 在 2025/8/26 11:21, SeongJae Park 写道:
> > > [...]
> > >
> > > > > ==== Attachment 0 (0001-mm-damon-paddr-use-do_div-on-i386-for-damon_pa_pageo.patch) ====
> > > > >    From hackermail Thu Jan  1 00:00:00 1970
> > > > > From: SeongJae Park <sj@xxxxxxxxxx>
> > > > > To: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > > > > Cc: SeongJae Park <sj@xxxxxxxxxx>
> > > > > Cc: damon@xxxxxxxxxxxxxxx
> > > > > Cc: kernel-team@xxxxxxxx
> > > > > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > > > > Cc: linux-mm@xxxxxxxxx
> > > > > Date: Mon, 25 Aug 2025 07:41:33 -0700
> > > > > Subject: [PATCH 1/3] mm/damon/paddr: use do_div() on i386 for damon_pa_pageout()
> > > > >             return value
> > > > >
> > > > > Otherwise, __udidi3 linking problem happens on certain configs.
> > > > >
> > > > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > > > Closes: https://lore.kernel.org/oe-kbuild-all/202508241831.EKwdwXZL-lkp@xxxxxxxxx/
> > > > > Signed-off-by: SeongJae Park <sj@xxxxxxxxxx>
> > > > > ---
> > > > >     mm/damon/paddr.c | 14 +++++++++++++-
> > > > >     1 file changed, 13 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> > > > > index 5fad2f9a99a0..09c87583af6c 100644
> > > > > --- a/mm/damon/paddr.c
> > > > > +++ b/mm/damon/paddr.c
> > > > > @@ -135,6 +135,18 @@ static bool damon_pa_invalid_damos_folio(struct folio *folio, struct damos *s)
> > > > >     	return false;
> > > > >     }
> > > > >     
> > > > > +/* convert physical address to core-layer address */
> > > > > +static unsigned long damon_pa_core_addr(phys_addr_t pa,
> > > > > +		unsigned long addr_unit)
> > > > > +{
> > > > > +#ifdef __i386__
> > > > Can we use the following condition instead?
> > > >
> > > > #if !defined(CONFIG_64BIT) && defined(CONFIG_PHYS_ADDR_T_64BIT)
> > > To my understanding, this issue happens only on i386, not every 32bit
> > > architectures.  So I think i386 specific condition is better.
> > I understand. However, the aforementioned general condition is essential,
> > and we should propose a new patch to address this. After introducing addr_unit,
> > any 32-bit architecture should support monitoring of 64-bit phys_addr_t.
> The issue is that we cannot divide 64bit values with plain '/' operator on
> "i386", and hence this patch makes it to use do_div() instead of '/' on "i386".
> No such or other problems at supporting 64-bit phys_addr_t is found on other
> 32bit architectures, to my understanding.  My understanding is that at least
> you confirmed that on your arm-based test environment.  So we don't need a new
> patch to my understanding.
>
> Am I missing somthing?

This is because I seem to have made a mistake earlier: I adjusted the local
compilation toolchain. When the __udivdi3 issue mentioned above occurred, it
reminded me of a potential problem. After switching to a completely new environment
for testing, I discovered the __aeabi_uldivmod linking error in arm, which is similar
to the __udivdi3 issue.🙁 To prevent similar environment-related problems in the
future, I suggest adjusting the condition to the following:

#if !defined(CONFIG_64BIT) && defined(CONFIG_PHYS_ADDR_T_64BIT)

Please consider approving this fix.


Best regards,
Quanmin Yan


[...]