[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <464f9f46-6ed5-4a78-8e06-878869f2afc4@huawei.com>
Date: Tue, 26 Aug 2025 12:51:17 +0800
From: Quanmin Yan <yanquanmin1@...wei.com>
To: SeongJae Park <sj@...nel.org>
CC: <akpm@...ux-foundation.org>, <damon@...ts.linux.dev>,
<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
<wangkefeng.wang@...wei.com>, <zuoze1@...wei.com>, <kernel-team@...a.com>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2 03/11] mm/damon/paddr: support addr_unit for
DAMOS_PAGEOUT
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@...nel.org>
>>> To: Andrew Morton <akpm@...ux-foundation.org>
>>> Cc: SeongJae Park <sj@...nel.org>
>>> Cc: damon@...ts.linux.dev
>>> Cc: kernel-team@...a.com
>>> Cc: linux-kernel@...r.kernel.org
>>> Cc: linux-mm@...ck.org
>>> 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@...el.com>
>>> Closes: https://lore.kernel.org/oe-kbuild-all/202508241831.EKwdwXZL-lkp@intel.com/
>>> Signed-off-by: SeongJae Park <sj@...nel.org>
>>> ---
>>> 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.
What do you think should be our next step? Looking forward to your reply.
Thanks,
Quanmin Yan
[...]
Powered by blists - more mailing lists