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

David Hildenbrand david at redhat.com
Tue Jun 24 01:37:51 AEST 2025


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



More information about the Linuxppc-dev mailing list