[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e03b278-aaeb-d11c-d2e0-d45ca5e97346@huawei.com>
Date: Sat, 30 Mar 2024 20:01:14 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>, "davem@...emloft.net"
<davem@...emloft.net>, "kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, David Howells
<dhowells@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH RFC 01/10] mm: Move the page fragment allocator from
page_alloc into its own file
On 2024/3/30 1:19, Christophe Leroy wrote:
>
>
> Le 28/03/2024 à 14:38, Yunsheng Lin a écrit :
>> Inspired by [1], but use free_unref_page() to replace free_the_page()
>> instead of __free_pages(), use VM_BUG_ON() to catch that we can use
>> free_unref_page() directly, also add its own header file.
>>
>> As the API is only used by the networking, it may make sense to
>> move it to the networking directory like the page_pool does in the
>> future if we can make the free_unref_page() callable outside of the
>> mm subsystem. And we can utilize that to decouple the 'struct page'
>> in the networking subsystem in the future.
>
> I'm wondering if this page fragment allocator could replace the page
> fragment allocator used in powerpc to allocate fragment of pages for
> page tables.
>From a quick glance, it seems possible. If there are potential users
other than the networking for this API, we can keep it in mm subsystem
for now as this patch does and see how thing will evolve.
>
> See arch/powerpc/mm/pgtable-frag.c
>
> Christophe
>
Powered by blists - more mailing lists