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

[Linus Torvalds]

On Mon, 9 Nov 2026 at 09:24, David Hildenbrand (Arm) <david@xxxxxxxxxx> 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.

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)

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.

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.

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

                    Linus