Hello, On Fri, Jun 21, 2024 at 02:37:43PM -0700, Namhyung Kim wrote: > > > - cgroup_threadgroup_rwsem > > > > This one shouldn't matter at all in setups where new cgroups are populated > > with CLONE_INTO_CGROUP and not migrated further. The lock isn't grabbed in > > such usage pattern, which should be the vast majority already, I think. Are > > you guys migrating tasks a lot or not using CLONE_INTO_CGROUP? > > I'm afraid there are still some use cases in Google that migrate processes > and/or threads between cgroups. :( I see. I wonder whether we can turn this into a cgroup lock. It's not straightforward tho. It's protecting migration against forking and exiting and the only way to turn it into per-cgroup lock would be tying it to the source cgroup as that's the only thing identifiable from the fork and exit paths. The problem is that a single atomic migration operation can pull tasks from multiple cgroups into one destination cgroup, even on cgroup2 due to the threaded cgroups. This would be pretty rare on cgroup2 but still need to be handled which means grabbing multiple locks from the migration path. Not the end of the world but a bit nasty. But, as long as it's well encapsulated and out of line, I don't see problems with such approach. As for cgroup_mutex, it's more complicated as the usage is more spread, but yeah, the only solution there too would be going for finer grained locking whether that's hierarchical or hashed. Thanks. -- tejun
