Re: [PATCH v2 1/2] mm/huge_memory: use folio's memcg inside __folio_split()

On Tue, Aug 4, 2026 at 1:55 AM Zi Yan <[email protected]> wrote:
>
> On 3 Aug 2026, at 13:25, Kairui Song wrote:
>
> > On Tue, Aug 4, 2026 at 12:53 AM Zi Yan <[email protected]> wrote:
> >>
> >> On Mon Aug 3, 2026 at 11:07 AM EDT, Lorenzo Stoakes (ARM) wrote:
> >>> No __folio_split().
> >>>
> >>> Comment about cleanup.h really was the whole pattern of goto xxx for various
> >>> levels of unwinding things.
> >>>
> >>> But really I mean the folio splitting code in general, there's a lot of
> >>> massive-complicated-functions with a million things going on at once,
> >>> __folio_freeze_and_split_unmapped() is another.
> >>>
> >>> Feels like we should really have this stuff in something like mm/folio.c anyway
> >>> too now that's renamed :)
> >>>
> >>
> >> I agree that __folio_split() is handling multiple cases, anon, shmem,
> >> pagecache, all together. Do you prefer:
> >>
> >> 1. split __folio_split() to handle each case in a separate function with
> >> some code duplication, like xarray for pagecache and shmem,
> >> freeze/unfreeze folio for all;
> >
> > Hi all,
> >
> > Do you like a __folio_freeze_split_unmap /
> > __folio_freeze_split_unmap_file split? :),  I'm asking this as I'm
> > currently trying to sort up the mess about swap cache in huge_memory.c
> > and found it will be much cleaner if we move file related code into
> > __folio_freeze_split_unmap_file, and let __folio_freeze_split_unmap
> > handle anon and swap cache, and then saw the discussion here. (A bit
>
> Sounds good to me.
> Maybe s/__folio_freeze_split_unmap/__folio_freeze_split_unmap_anon/
> to be specific?

We will have to deal with clean (not yet added to anon) swap cache;
I'm not sure if that counts as anon? I'm fine either way about naming
though.

> > more detail on this, I think we ca just assume we just don't need or
> > want shmem swapcache split, because shmem swap cache is meant to be an
> > intermediate state during IO, and shmem drops swap cache once IO
> > compete, and hybrid half-tmpfs-half-swap state is really ugly and
> > should be avoided competely, swap cache lookup is still fine for shmem
> > just make sure the folio is not in shmem's mapping).
>
> The reason looks good to me. Can you remove the shmem in swapcache TODO
> and firmly say shmem in swapcache is not supported due to the above reason
> when you split the code?

Sure, will do. Thanks!