On 18.06.25 22:04, Matthew Wilcox wrote:

On Wed, Jun 18, 2025 at 03:25:46PM -0400, Zi Yan wrote:

quoted

On 18 Jun 2025, at 15:18, Matthew Wilcox wrote:

quoted

quoted

Why not use page version of lock, unlock, and put? Especially you are
thinking about not using folio for these pages. Just a question,
I am OK with current patch.

That would reintroduce unnecessary calls to compound_head().

Right. And I want to make it clear that everything that uses "folio" 
here must be reworked: not necessarily switching to the "page" variant, 
but actually by implementing it entirely differently.

(e.g., store them in an array instead of a list, get rid of the lock 
bit, try getting rid of the refcount as well)

quoted

Got it. But here page is not folio, so it cannot be a compound page.
Then, we will need page versions without compound_head() for
non compound pages. Could that happen in the future when only folio
can be compound and page is only order-0?

I think the assumption that we'll only see compound pages as part of
folios is untrue.  For example, slabs will still allocate multiple
pages (though slabs aren't migratable at this point).  The sketch at
https://kernelnewbies.org/MatthewWilcox/Memdescs supports "misc pages"
with an order stored in bits 12-17 of the memdesc.  I don't know
how useful that will turn out to be; maybe we'll never implement that.

Once we have to support that for movable_ops, it will be an interesting 
question how to handle that. Most certainly, these things will not be 
folios. :)

-- 
Cheers,

David / dhildenb