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

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? I assume shmem is handled in file part, since you said
below shmem in swapcache is not worth the support.

> 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?

>
> LOC seems lower with the split and swap part cleaned, they really
> don't share much logic anyway, except for a for loop for putting the
> splitted folio back to filemapping / swap cache, and a folio freeze
> check.
>
> And after doing that, for swap, splitting clean swap cache and
> splitting swap cache to higher order are easily supported, a few ugly
> checks are gone, we can't do that now partly because the code there is
> really complex.

Looking forward to your patches. :)


Best Regards,
Yan, Zi