[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCII7vd3C2gB0oi_@casper.infradead.org>
Date: Mon, 12 May 2025 15:42:54 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Byungchul Park <byungchul@...com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, kernel_team@...ynix.com, kuba@...nel.org,
almasrymina@...gle.com, ilias.apalodimas@...aro.org,
harry.yoo@...cle.com, hawk@...nel.org, akpm@...ux-foundation.org,
ast@...nel.org, daniel@...earbox.net, davem@...emloft.net,
john.fastabend@...il.com, andrew+netdev@...n.ch,
edumazet@...gle.com, pabeni@...hat.com, vishal.moola@...il.com
Subject: Re: [RFC 19/19] mm, netmem: remove the page pool members in struct
page
On Mon, May 12, 2025 at 09:51:03PM +0900, Byungchul Park wrote:
> On Fri, May 09, 2025 at 07:02:30PM +0100, Matthew Wilcox wrote:
> > > + struct __netmem_desc place_holder_1; /* for page pool */
> > > struct { /* Tail pages of compound page */
> > > unsigned long compound_head; /* Bit zero is set */
> > > };
> >
> > The include and the place holder aren't needed.
>
> Or netmem_desc overlaying struct page might be conflict with other
> fields of sturct page e.g. _mapcount, _refcount and the like, once the
> layout of struct page *extremly changes* in the future before
> netmem_desc has its own instance.
That's not how it'll happen. When the layout of struct page changes,
it'll shrink substantially (cut in half). That means that dynamically
allocating netmem_desc must happen first (along with slab, folio, etc,
etc).
Powered by blists - more mailing lists