Re: [PATCH 6.6.y] mm/huge_memory: use folio's memcg inside __folio_split()

["Zi Yan" <ziy@nvidia.com>]

On Sun Sep 6, 2026 at 9:33 AM EDT, Sasha Levin wrote:
>> __GFP_ACCOUNT is needed for xarray node allocation accounting when
>> XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache
>> convergence regression") fixed a workingset regression with it.
>> xas_split_alloc() does not have it and needs to be fixed.
>
> Mainline's c299a2285d9d takes a reference on the folio's memcg with
> get_mem_cgroup_from_folio() and holds it in current->active_memcg for the
> duration of __folio_split() - rcu_read_lock()+css_tryget(), released with
> mem_cgroup_put() afterwards. This 6.6.y version instead holds a bare
> folio_memcg(folio) pointer across the same window, which includes a TLB
> shootdown and several lock acquisitions - exactly the kind of window the
> upstream refcount exists to close.
>
> 6.6 already has rcu_read_lock(), css_tryget() and mem_cgroup_put() available,
> so nothing's missing to do this the same way upstream does.  Could you resend a
> v2 that takes and drops the reference (under CONFIG_MEMCG, as upstream does)?

No, this is not needed. Before commit f1cf8d2f36dc3 ("mm: memcontrol:
eliminate the problem of dying memory cgroup for LRU folios"), like
v6.6, a charged folio take a ref on its memcg. During split, the folio
is locked, so will not be uncharged. As a result, its memcg will not go
away.

According to Claude, adding a ref there might cause a deadlock when a
to-be-split folio has a dying memcg, where css_tryget() keeps failing
and folio_memcg() keeps returning the same memcg.

This should also apply to v6.1. I will send my version for 6.1 backport.


-- 
Best Regards,
Yan, Zi