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

[Kairui Song <ryncsn@gmail.com>]

On Thu, Aug 27, 2026 at 10:22:56PM +0800, David Hildenbrand (Arm) wrote:
> On 8/27/26 19:48, Kairui Song wrote:
> > On Fri, Aug 28, 2026 at 12:51 AM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 8/20/26 20:55, Kairui Song via B4 Relay wrote:
> >>> From: Kairui Song <kasong@tencent.com>
> >>>
> >>> 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@nvidia.com>
> >>> Signed-off-by: Kairui Song <kasong@tencent.com>
> >>> ---
> >>
> >> 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?

It seems actually not hard to drop these two, and keep mostly of the cleanup,
will send a V4 as pure cleanup and tiny fixes. And without these two change
it actually looks cleaner, and shorter to review. Swap cache support can done
seperately later.