linux-kernel - Re: A path forward to cleaning up dying cgroups?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMgjq7BjBoCWeB-MwUGYA=jLvigZ6tC3pLxz6SHAj3eVcsCgnA@mail.gmail.com>
Date: Thu, 6 Feb 2025 12:56:03 +0800
From: Kairui Song <ryncsn@...il.com>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>, Muchun Song <muchun.song@...ux.dev>
Cc: Johannes Weiner <hannes@...xchg.org>, Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>, 
	linux-mm@...ck.org, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Andrew Morton <akpm@...ux-foundation.org>, 
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Tejun Heo <tj@...nel.org>, Michal Koutný <mkoutny@...e.com>, 
	Michal Hocko <mhocko@...nel.org>, "Zach O'Keefe" <zokeefe@...gle.com>, Kinsey Ho <kinseyho@...gle.com>, 
	Yosry Ahmed <yosryahmed@...gle.com>, Allen Pais <apais@...ux.microsoft.com>
Subject: Re: A path forward to cleaning up dying cgroups?

On Thu, Feb 6, 2025 at 2:16 AM Yosry Ahmed <yosry.ahmed@...ux.dev> wrote:
>
> On Wed, Feb 05, 2025 at 01:08:42PM -0500, Johannes Weiner wrote:
> > On Wed, Feb 05, 2025 at 12:50:19PM -0500, Hamza Mahfooz wrote:
> > > Cc: Shakeel Butt <shakeel.butt@...ux.dev>
> > >
> > > On 2/5/25 12:48, Hamza Mahfooz wrote:
> > > > I was just curious as to what the status of the issue described in [1]
> > > > is. It appears that the last time someone took a stab at it was in [2].
> >
> > If memory serves, the sticking point was whether pages should indeed
> > be reparented on cgroup death, or whether they could be moved
> > arbitrarily to other cgroups that are still using them.
> >
> > It's a bit unfortunate, because the reparenting patches were tested
> > and reviewed, and the arbitrary recharging was just an idea that
> > ttbomk nobody seriously followed up on afterwards.
>
> There was an RFC series [1] for the recharging, but all memcg
> maintainers hated it :P
>
> https://lore.kernel.org/lkml/20230720070825.992023-1-yosryahmed@google.com/

We have been suffering from dying cgroup issues for years too, and I
just saw this series. Will it be a good idea to combine this with
reparenting instead (if we will go with the reparenting approach)?
Using objcg API to charge the folios does help speed up the
reparenting, but also adds some overhead and complexity. Just walking
and reparenting the folios seems a more direct approach.

And another idea is, per our observation, dying cgroups have few pages
that are mapped, as the process has all exited. Most folios are just
cache. Shared mapped pages are minor especially for containers. So a
deferred recharge on access seems good enough? Mapped folios may also
be finally unmap someday and get recharged. And at least this makes
accounting more accurate.