Re: [RFC PATCH v2 01/18] mm: free PG_rcu_free folios only after an RCU grace period

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/9/26 19:01, Linus Torvalds wrote:
> On Mon, 9 Nov 2026 at 09:24, David Hildenbrand (Arm) <david@kernel.org> wrote:
>>>
>>> I think trying to corral it into some special case is the last thing
>>> we want to do. It only makes things less potentially useful and more
>>> fragile.
>> Let me wrap my head around how this would look when we decouple pages from
>> folios, where pages might not have a ->lru anymore, or not even a refcount.
> 
> So for an example of a place that already does RCU freeing of pages -
> *not* folios - look at the TLB shootdown.

Yes, I am well aware of that handling. Unfortunately. :)

> 
> It's very round-about and hard to tell, but it's using
> 
>   tlb_remove_table_free
>     call_rcu(&batch->rcu, tlb_remove_table_rcu);
> 
> and that then does
> 
>   tlb_remove_table_rcu ->
>     __tlb_remove_table_free ->
>       __tlb_remove_table ->
>         pagetable_dtor_free ->
>           pagetable_free ->
>             __pagetable_free ->
>                __free_pages(page, compound_order(page))
> 
> (and I might have messed this up - this really is a rats nest of
> nested inline functions).
> 
> And in order to do this all, it sets up *another* page just to contain
> the batching (which is also RCU-free'd)

Yeah, I recall some details about ->lru not being usable (as reused for other
purposes by some architectures) and some things about multiple page tables
residing in a single physical page on some architectures (at least powerpc),
which makes using ptdesc / ->lru impossible as well, as we might only be freeing
parts of a page instead of full pages.

And some page tables today might already be allocated from slab (I think at
least sparc64 and m68k do that).

So that's one of the reason why tlb_remove_table() consumes a void * pointer
instead of a page/ptdesc pointer. It's all linked to
CONFIG_HAVE_ARCH_TLB_REMOVE_TABLE IIRC.

> 
> Now, the batching is probably a very good thing in that context, so
> I'm not actually suggesting this should be converted to some common
> RCU-freeing thing.
> 
> Rather, I'm pointing out that we have existing hacks in this area that
> have grown up over time and would have been a *lot* less hacky if we
> had had a proper RCU-freeing page allocator back when that whole TLB
> freeing code was written.

See, I am not sure about that given the challenge with
CONFIG_HAVE_ARCH_TLB_REMOVE_TABLE. And apparently powerpc is using that, which
is not quite the museum piece (compared to m68k and sparc64 :) )

In a perfect world without these corner cases that make our life hard, possibly.

> 
> So I'm not saying "we should unify this". But I *am* saying "look, RCU
> freeing of pages is _already_ a thing, and we have complicated hacky
> things in place for it".
> 
> And they are complicated not because they necessarily should be
> complicated, but because we solved the TLB shootdown after we already
> had tons of complex architecture-specific code in place, and we
> basically ended up adding that RCU phase on top of that existing
> per-architecture complexity and abstraction.

Jup.

> 
> *NOW* it would be actually fairly painful to try to convert the TLB
> shootdown to a new order. But originally, it would have been very nice
> if we had just had a "Oh, mark this page for RCU freeing".
> 
> (In all fairness, we also did it that way because some architectures
> don't need the RCU delay simply because they have some other hardware
> page walking infrastructure than the actual page tables the kernel
> builds up. Not that those architectures *matter* today, but some of
> that per-architecture inline function stuff is required to basically
> isolate these kinds of decisions from the MM code - that deep inline
> function indirection has a reason that is entirely independent of the
> freeing side).

There are some dirty details when it comes to the upcoming page vs. folio split
that I am still unclear about.

The page table example you mention above is another prime example of the
challenges we'll face: page tables will have a separately allocated memdesc
("ptdesc"), just like folios will have their memdesc ("folio") separately allocated.

When RCU freeing, we'll really have to keep the allocated memdesc alive as well.
RCU-freeing the page only is not sufficient.

There was even talk about allocating page tables from slab later, as long as we
can adjust a "struct ptdesc" to it. Which would solve the problem of powerpc
etc. that don't operate on full pages for page tables.

So I might be completely off, but what I imagine is that the memdescs will get
RCU-freed (these are not pages), and once they are then getting freed, they will
probably take the physical page with them.

And freeing memdescs through RCU will likely be memdesc specific.

I really don't know, Willy might know more about these plans.

But I am overloaded with all the Fixes, so my brain doesn't work quite right.

-- 
Cheers,

David