[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ef34638-a3e3-4e86-a96e-bc4694661adb@bytedance.com>
Date: Mon, 5 Feb 2024 00:26:37 +0800
From: Qi Zheng <zhengqi.arch@...edance.com>
To: Mike Rapoport <rppt@...nel.org>, akpm@...ux-foundation.org
Cc: arnd@...db.de, muchun.song@...ux.dev, david@...hat.com,
willy@...radead.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/2] mm: pgtable: add missing flag and statistics for
kernel PTE page
On 2024/2/4 20:15, Mike Rapoport wrote:
> On Sun, Feb 04, 2024 at 07:39:38PM +0800, Qi Zheng wrote:
>> Hi Mike,
>>
>> On 2024/2/4 18:58, Mike Rapoport wrote:
>>> On Thu, Feb 01, 2024 at 04:05:40PM +0800, Qi Zheng wrote:
>>>> For kernel PTE page, we do not need to allocate and initialize its split
>>>> ptlock, but as a page table page, it's still necessary to add PG_table
>>>> flag and NR_PAGETABLE statistics for it.
>>>>
>>>> Signed-off-by: Qi Zheng <zhengqi.arch@...edance.com>
>>>> ---
>>>> include/asm-generic/pgalloc.h | 7 ++++++-
>>>> include/linux/mm.h | 21 ++++++++++++++++-----
>>>> 2 files changed, 22 insertions(+), 6 deletions(-)
>>>
>>> This should also update the architectures that define
>>> __HAVE_ARCH_PTE_ALLOC_ONE_KERNEL, otherwise NR_PAGETABLE counts will get
>>> wrong.
>>
>> Yes, this patchset only focuses on the generic implementation. For those
>> architectures that define __HAVE_ARCH_PTE_ALLOC_ONE_KERNEL, some reuse
>> the generic __pte_alloc_one_kernel(), but some have their own customized
>> implementations, which indeed need to be fixed.
>>
>> I wasn't familiar with those architectures and didn't investigate why
>> they couldn't reuse the generic __pte_alloc_one_kernel(), so I didn't
>> fix them.
>
> But with your patch NR_PAGETABLE will underflow e.g. on arm and it'd be a
> regression for no good reason.
Oh, I see. In some architectures, they implement their own
pte_alloc_one_kernel() and do not call generic __pte_alloc_one_kernel(),
but still reuse generic pte_free_kernel(). So it needs to be fixed
together.
I will try to fix them and send the v2. But since I'm on vacation
recently, updates may not be quick.
Hi Andrew, please help to temporarily remove this patchset from the
mm-unstable.
Thanks!
>
>> It would be better if there are maintainers corresponding to
>> the architecture who can help fix it. After all, they have a better
>> understanding of the historical background and have a testing
>> environment. ;)
>
Powered by blists - more mailing lists