[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