Re: [PATCH 0/3] mm: support splitting mappingless swapcache folios

[Kairui Song <ryncsn@gmail.com>]

On Wed, Aug 05, 2026 at 08:03:33AM +0800, Zi Yan wrote:
> On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote:
> 
> > Large shmem folios lose their address-space mapping when they are written
> > to swap, but remain valid members of the swap cache. Folios read from swap
> > but not yet associated with an anon_vma can have the same mappingless
> > swapcache state. folio_check_splittable() currently mistakes both cases for
> > truncation and rejects the split with -EBUSY.
> >
> > Implement the longstanding TODO for this state. Allow mappingless
> > swapcache folios to use the existing uniform order-0 swapcache split path,
> > while continuing to reject truly truncated folios and unsupported
> > higher-order or non-uniform swapcache splits.
> 
> Thank you for your patches.
> 
> As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”),
> we might not need to implement this split. I will let Kairui to decide
> how we should deal with this patchset.
> 
> [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/

Thanks for the CC, this is actually not hard to implement as shown by
Shivam, I just found the code more and more hard to follow and fragile
as we add more logic to it. And we don't have to reject higher order
split either which can be seen easily if the code is cleaner.

Personally I think doing some cleanup first is better, I haven't post any
code as right now there doesn't seem to be much user of this. It will be
needed if more clean THP swapcache begin to show up due to things like
THP readahead for swap, which isn't here yet. I think I can send an RFC
tomorrow just for reference. I'm fine if we prefer to remove that TODO
using this smaller change first :)