Re: [PATCH v3 15/18] mm/huge_memory: lift order-0 restriction for swapcache split

[David Hildenbrand (Arm)]

On 8/27/26 19:48, Kairui Song wrote:
> On Fri, Aug 28, 2026 at 12:51 AM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
>>
>> On 8/20/26 20:55, Kairui Song via B4 Relay wrote:
>>> From: Kairui Song <kasong@xxxxxxxxxxx>
>>>
>>> The restriction that swapcache folios can only be uniformly split to
>>> order 0 dates back to when the swap cache was managed via address_space
>>> mapping (swap_address_space).  The old split loop only created order-0
>>> sub-folios with a fixed stride, so non-uniform split and non-zero order
>>> were rightfully blocked.
>>>
>>> After the swap cache switched to swap table under a cluster lock,
>>> __swap_cache_replace_folio already gained the ability to replace any
>>> number of entries for any sub-folio size in one cluster, and the old
>>> swap_address_space locking and limit was removed. The restriction
>>> became obsolete but persisted through multiple refactorings.
>>>
>>> Drop it now: swapcache folios can be split to any supported order with
>>> either uniform or non-uniform split, except order-1 which is not
>>> supported for anon folios. Mappingless swap cache folios could be either
>>> anon or shmem, so for now we just simply forbid order-1 for all swapcache.
>>>
>>> Acked-by: Zi Yan <ziy@xxxxxxxxxx>
>>> Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
>>> ---
>>
>> In contrast to the other cleanup patches, this patch changes behavior.
>>
>> I would suggest to send all cleanups first, and send this out separately, such
>> that it gets proper attention and doesn't get buried in a sequence of
>> harmlessly-looking cleanups :)
> 
> No problem, send this later then :)

On second thought, the

"mm/huge_memory: allow splitting mappingless swap cache folios"

is already such a change. And I guess only having both these behavior-changing
things separated from the cleanups might be harder, right?

-- 
Cheers,

David