[LSF/MM/BPF TOPIC] Separately allocating memdescs from struct page

[LSF/MM/BPF TOPIC] Separately allocating memdescs from struct page

[Vishal Moola (Oracle)]

As part of the overarching project to shrink struct page, we've been
creating memdescs that currently function as wrappers around it[1].
Until we separately allocate memdescs, we won't be able to shrink the
page.

We're getting close to being able to allocate memdescs separately from
struct page, and I'd like to propose the topic to discuss how we want
to go about it. We already have Matthew's PoC for ptdescs[2]. I've taken
that on, but we're still running into issues for now...

Heres a non-exhaustive list of things I'd like to discuss:
- What memdescs to separate allocate for shrinking the page right now
- What are the implications of separate allocations
- Should we separately allocate one at a time, or all at once
- How the APIs would look
- Are there other generic fields to be cautious about (i.e. memcg)

I imagine Matthew might have a broader State of the Page talk too, so
this would be more in-depth. Possibly focused on ptdesc & slab (as the
two we're actively looking at right now).

[1] https://kernelnewbies.org/MatthewWilcox/Memdescs
[2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/

Re: [LSF/MM/BPF TOPIC] Separately allocating memdescs from struct page

[Vishal Moola]

On Wed, Feb 25, 2026 at 11:19 PM Vishal Moola (Oracle)
<vishal.moola@gmail.com> wrote:
>
> As part of the overarching project to shrink struct page, we've been
> creating memdescs that currently function as wrappers around it[1].
> Until we separately allocate memdescs, we won't be able to shrink the
> page.
>
> We're getting close to being able to allocate memdescs separately from
> struct page, and I'd like to propose the topic to discuss how we want
> to go about it. We already have Matthew's PoC for ptdescs[2]. I've taken
> that on, but we're still running into issues for now...
>
> Heres a non-exhaustive list of things I'd like to discuss:
> - What memdescs to separate allocate for shrinking the page right now
> - What are the implications of separate allocations
> - Should we separately allocate one at a time, or all at once
> - How the APIs would look
> - Are there other generic fields to be cautious about (i.e. memcg)
>
> I imagine Matthew might have a broader State of the Page talk too, so
> this would be more in-depth. Possibly focused on ptdesc & slab (as the
> two we're actively looking at right now).
>
> [1] https://kernelnewbies.org/MatthewWilcox/Memdescs
> [2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/

I've linked the slides to the presentation [1].

Theres a mistake in slide 4, the correct labelling of the words (to the
current page) should be as follows:

struct folio {
        memdesc_flags_t flags;          //word 1
        struct list_head lru;           //words 2+3
        struct address_space *mapping;  //word 4
        pgoff_t index;                  //word 5
        void *private;                  //word 6
        unsigned int _refcount;         //word 7 (first half)
        unsigned int _mapcount;         //word 7 (2nd half)
        struct mem_cgroup *memcg;       //word 8

        /* Below are for order-0 folios */
        unsigned int pincount;
        unsigned char order;
        unsigned long pfn;
        /* Large folios will store more information here */
};

[1] https://drive.google.com/drive/folders/1KGlxnmg-nQ64uAK8KBp8DyNYiaVbTWGF?usp=drive_link

Re: [LSF/MM/BPF TOPIC] Separately allocating memdescs from struct page

[Vishal Moola]

On Wed, May 6, 2026 at 8:03 PM Vishal Moola <vishal.moola@gmail.com> wrote:
>
> On Wed, Feb 25, 2026 at 11:19 PM Vishal Moola (Oracle)
> <vishal.moola@gmail.com> wrote:
> >
> > As part of the overarching project to shrink struct page, we've been
> > creating memdescs that currently function as wrappers around it[1].
> > Until we separately allocate memdescs, we won't be able to shrink the
> > page.
> >
> > We're getting close to being able to allocate memdescs separately from
> > struct page, and I'd like to propose the topic to discuss how we want
> > to go about it. We already have Matthew's PoC for ptdescs[2]. I've taken
> > that on, but we're still running into issues for now...
> >
> > Heres a non-exhaustive list of things I'd like to discuss:
> > - What memdescs to separate allocate for shrinking the page right now
> > - What are the implications of separate allocations
> > - Should we separately allocate one at a time, or all at once
> > - How the APIs would look
> > - Are there other generic fields to be cautious about (i.e. memcg)
> >
> > I imagine Matthew might have a broader State of the Page talk too, so
> > this would be more in-depth. Possibly focused on ptdesc & slab (as the
> > two we're actively looking at right now).
> >
> > [1] https://kernelnewbies.org/MatthewWilcox/Memdescs
> > [2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/
>
> I've linked the slides to the presentation [1].
>
> Theres a mistake in slide 4, the correct labelling of the words (to the
> current page) should be as follows:
>
> struct folio {
>         memdesc_flags_t flags;          //word 1
>         struct list_head lru;           //words 2+3
>         struct address_space *mapping;  //word 4
>         pgoff_t index;                  //word 5
>         void *private;                  //word 6
>         unsigned int _refcount;         //word 7 (first half)
>         unsigned int _mapcount;         //word 7 (2nd half)

I keep messing up minor things in my haste :/. Refcount actually
is below mapcount, woops.
The slides have that part right xD[1].

>         struct mem_cgroup *memcg;       //word 8
>
>         /* Below are for order-0 folios */
>         unsigned int pincount;
>         unsigned char order;
>         unsigned long pfn;
>         /* Large folios will store more information here */
> };
>

[1] https://drive.google.com/drive/folders/1KGlxnmg-nQ64uAK8KBp8DyNYiaVbTWGF?usp=drive_link