Re: MM global locks as core counts quadruple

[Tejun Heo <tj@kernel.org>]

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