Re: [PATCH v2] cgroup: avoid css_set_lock in cgroup_css_set_fork()

[Michal Koutný]

On Wed, Mar 11, 2026 at 03:41:56PM +0100, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
> So I booted up a vm with 80 hw threads and the cgroup lock is still
> top of the profile for me when rolling with ./threadspawn1_processes
> -t 80
> 
> While I prefer my patch on the grounds it reduces overhead to begin
> with (fewer locking trips), I wont argue against yours. My primary
> goal here is to get cgroups out of the way.

I filed this under -- there are still other locks above css_set_lock.
Has this changed with current mainline?

Furthermore, there's still: a) css_set_lock in post_fork and b) tasklist
lock which is much harder problem.

> 
> or to put it differently, can you either ack my patch or push yours?

Without a convincing measurement, I'd say either are making
synchronization more complex for nothing.

What contention numbers do you see before and after the patch (on what
base)?
(Sorry, I dismantled my measuring environment meanwhile (and I wouldn't
know what other non-mainline patches would I need).)

Thanks,
Michal

Attachment: signature.asc
Description: PGP signature