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

[Mina Almasry <almasrymina@google.com>]

On Sun, Apr 13, 2025 at 6:36 PM Byungchul Park <byungchul@sk.com> 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
>
> My first goal is to remove fields for page pool from struct page like:
>

Remove them, but put them where? The page above specificies "Split the
pagepool bump allocator out of struct page, as has been done for, eg,
slab and ptdesc.", but I'm not familiar what happened with slab and
ptdesc. Are these fields moving to a different location? Or being
somehow removed entirely?

>    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'.
>

Yeah, we did it to support non-page memory in the net stack, which is
quite orthogonal to what you're trying to do AFAICT so far. Looks like
maybe some implementation details are shared by luck?

> 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.
>
>    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?

Need more details. What does struct bump represent? If it's meant to
replace the fields used by the page_pool referenced above, then it
should not have _page_flags, bump_ref_count should be pp_ref_count,
and should not have _page_type or _refcount.

> 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.
>

What is the terminology "bump"? Are you wanting to rename page_pool to
"bump"? What does the new name mean?

-- 
Thanks,
Mina