Re: [RFC] shrinking struct page (part of page pool)

[Byungchul Park <byungchul@sk.com>]

On Tue, Apr 15, 2025 at 04:22:31PM -0700, Vishal Moola (Oracle) wrote:
> On Mon, Apr 14, 2025 at 10:36:27AM +0900, Byungchul Park wrote:
> > Hi guys,
> > 
> > I'm looking at network's page pool code to help 'shrinking struct page'
> > project by Matthew Wilcox.  See the following link:
> > 
> >    https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
> 
> Thanks for looking at this!
> 
> > My first goal is to remove fields for page pool from struct page like:
> > 
> >    struct {	/* page_pool used by netstack */
> > 	/**
> > 	 * @pp_magic: magic value to avoid recycling non
> > 	 * page_pool allocated pages.
> > 	 */
> > 	unsigned long pp_magic;
> > 	struct page_pool *pp;
> > 	unsigned long _pp_mapping_pad;
> > 	unsigned long dma_addr;
> > 	atomic_long_t pp_ref_count;
> >    };
> > 
> > Fortunately, many prerequisite works have been done by Mina but I guess
> > he or she has done it for other purpose than 'shrinking struct page'.
> > 
> > I'd like to just finalize the work so that the fields above can be
> > removed from struct page.  However, I need to resolve a curiousity
> > before starting.
> 
> I have a blog that walks you through what I focused on when making
> ptdescs. It would benefit you to look at:
> 
> https://blogs.oracle.com/linux/post/introducing-memdesc

Hi bro,

Thank you for sharing the blog.

	Byungchul

> I'll need to start looking into the networking code before I can
> offer any opinions about the specifics of the descriptor though.
> 
> >    Network guys already introduced a sperate strcut, struct net_iov,
> >    to overlay the interesting fields.  However, another separate struct
> >    for system memory might be also needed e.g. struct bump so that
> >    struct net_iov and struct bump can be overlayed depending on the
> >    source:
> > 
> >    struct bump {
> > 	unsigned long _page_flags;
> > 	unsigned long bump_magic;
> > 	struct page_pool *bump_pp;
> > 	unsigned long _pp_mapping_pad;
> > 	unsigned long dma_addr;
> > 	atomic_long_t bump_ref_count;
> > 	unsigned int _page_type;
> > 	atomic_t _refcount;
> >    };
> > 
> > To netwrok guys, any thoughts on it?
> > To Willy, do I understand correctly your direction?
> > 
> > Plus, it's a quite another issue but I'm curious, that is, what do you
> > guys think about moving the bump allocator(= page pool) code from
> > network to mm?  I'd like to start on the work once gathering opinion
> > from both Willy and network guys.
> > 
> > 	Byungchul
> >