[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b5fe4c81-a7e6-4620-b0b6-a56ce7a2c304@csgroup.eu>
Date: Fri, 29 Mar 2024 17:19:14 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Yunsheng Lin <linyunsheng@...wei.com>, "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
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.
See arch/powerpc/mm/pgtable-frag.c
Christophe
Powered by blists - more mailing lists