Re: [PATCH v4 0/2] mm: improve folio refcount scalability

["Zi Yan" <ziy@nvidia.com>]

On Mon Jun 22, 2026 at 3:55 AM EDT, David Hildenbrand (Arm) wrote:
> On 6/21/26 03:40, Zi Yan wrote:
>> On Sat Jun 20, 2026 at 2:19 PM EDT,  wrote:
>>>>
>>>> Thanks. Nice numbers.
>>>>
>>>> AI review had some things to say:
>>>>  https://sashiko.dev/#/patchset/df26082871b4c65b2bd38d409026237c08572836@linux.dev
>>>

<snip>

>
>> 
>> For your patch, is it because of the separation of refcount-0 and
>> frozen? The page goes refcount-0 before it is frozen? 
>
> Exactly that. Refcount 0 is only transitional.
>
>> Will it work if
>> the page is frozen first then gets its refcount to 0? Basically, the
>> frozen state prevents anyone else messing up with your refcount.
>> 
>
> Let me comment the original sequence:
>
<snip>

>
> T1: BUG: calls dtor of type X on page of type Y
>

Since Ilya restarted working on this[1], I would like to get this issue
sorted out first.

[1] https://lore.kernel.org/all/85b0e3c5f328e2c3779fda986fa19530ae9c77d5@linux.dev/

>
> I am confused about the "dtor of type X vs. type Y". We have the page in our
> hand, once we won (2) we can lookup the type and do the right thing.
>
>
> I guess the interesting part is where the destructor is called from the outside:
>
> static inline void folio_put(struct folio *folio)
> {
> 	if (folio_put_testzero(folio))
> 		__folio_put(folio);
> }
>
> Where we keep operating on it as if it were a folio, although it might now be a
> non-folio thing.
>
> So if T1 is doing a folio_put(), we'd call into page_cache_release() etc with
> a non-folio thing.

Right.

>
> But IIUC, that can happen today already when we do
> folio_try_get(folio)+folio_put(folio) and it wasn't a folio in the first place?

Yes, it can happen today. But it is safe, because 1) __folio_put() can
handle non-folios, 2) page_frag_free() will not see a folio as it
holds a reference to the page. It is an important asymmetry.

After the patchset, both can see a changing page type. This means we
will need a generic page/folio free function to avoid calling the wrong
page dtor. In addition, when a to-be-put page is freed and reallocated
by another thread, its order can change. I am not sure how a generic
free function can handle it. For folios and compound pages, the order is
stored in struct folio/struct page. But some users allocate high-order
non-compound pages (not passing __GFP_COMP), so only the owner knows the
exact page order. Unless we convert all of them to use __GFP_COMP (we
will do that on the way to memdesc).

This issue needs to be sorted out first.

>
> I'd assume that will all change once the refcount moves into
> separately-allocated "struct folios".




-- 
Best Regards,
Yan, Zi