Re: [PATCH RFC 06/15] memcg, swap: reparent the swap entry on swapin if swapout cgroup is dead

[Kairui Song]

On Tue, Feb 24, 2026 at 1:44 PM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
>
> On Fri, Feb 20, 2026 at 07:42:07AM +0800, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@xxxxxxxxxxx>
> >
> > As a result this will always charge the swapin folio into the dead
> > cgroup's parent cgroup, and ensure folio->swap belongs to folio_memcg.
>
> I directly jump to this patch and the opening statement is confusing. Please
> make the commit message self contained.
>
> > This only affects some uncommon behavior if we move the process between
> > memcg.
> >
> > When a process that previously swapped some memory is moved to another
> > cgroup, and the cgroup where the swap occurred is dead, folios for
> > swap in of old swap entries will be charged into the new cgroup.
> > Combined with the lazy freeing of swap cache, this leads to a strange
> > situation where the folio->swap entry belongs to a cgroup that is not
> > folio->memcg.
>
> Why is this an issue (i.e. folio->swap's cgroup different from
> folio->memcg)?

It's an issue for this series, if we want to track the folio->swap
using folio->memcg to avoid an external array to record folio->swap's
memcgid.

>
> >
> > Swapin from dead zombie memcg might be rare in practise, cgroups are
> > offlined only after the workload in it is gone, which requires zapping
> > the page table first, and releases all swap entries. Shmem is
> > a bit different, but shmem always has swap count == 1, and force
> > releases the swap cache. So, for shmem charging into the new memcg and
> > release entry does look more sensible.
>
> Is this behavior same for all types of memory backed by shmem (i.e. MAP_SHARED,
> memfd etc)? What about cow anon memory shared between parent and child
> processes?

It's the same. If the memcg is dead and a swap entry's memcgid record
points to the dead memcg, then whoever reads this swap entry recharges
the swapin folio.