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

[Shakeel Butt <shakeel.butt@linux.dev>]

On Fri, Feb 20, 2026 at 07:42:07AM +0800, Kairui Song via B4 Relay wrote:
> From: Kairui Song <kasong@tencent.com>
> 
> 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)?

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

> 
> However, to make things easier to understand for an RFC, let's just
> always charge to the parent cgroup if the leaf cgroup is dead. This may
> not be the best design, but it makes the following work much easier to
> demonstrate.

Please add couple of line on how will it make things easier.