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

[David Hildenbrand (Arm)]

On 11/9/26 16:56, Linus Torvalds wrote:
> On Mon, 9 Nov 2026 at 06:43, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
>>
>> Can we just rework that code first to have some clear folio freeing path, IOW
>> doing this in a folio-specific helper?
> 
> I think you're making things worse rather than better.

The current code deals with pages vs. folios in ways that already makes this
code only work with folios even in the short term.

We'll be starting to let page_folio() fail soon on things that are not actual
folios. PG_folio for that is already in the works.

> 
> The whole point was to hook into *one* place: the page freeing.

Right, and I'd hook into the folio freeing path if it is folio-specific.

And we will need clean path for freeing folios either way as we are starting to
decouple struct page from struct folio as envisioned by Willy.

If we actually manage to make this generic for different memdescs in the future,
it can obviously stay on the generic path.

> 
> Trying to make it specific to one special freeing path only makes it
> fragile and less obvious, and results in anybody who then uses some
> other freeing model to miss the RCU thing.
> 
> It also means that suddenly nobody else can use the RCU path for their own uses.
> 
> Look at all the kmalloc RCU freeing: it's used all over the place. RCU
> has basically taken over the kernel. Every single performance-critical
> lock-free area of the kernel wants RCU freeing.
> 
> 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.

-- 
Cheers,

David