Re: [PATCH RFC 08/29] mm/migrate: rename putback_movable_folio() to putback_movable_ops_page()

[David Hildenbrand]

On 18.06.25 22:04, Matthew Wilcox wrote:
> On Wed, Jun 18, 2025 at 03:25:46PM -0400, Zi Yan wrote:
> > On 18 Jun 2025, at 15:18, Matthew Wilcox wrote:
> > > > 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)

> > 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