On 2012/7/21 4:05, Tejun Heo wrote:

Hey, Peter.

On Fri, Jul 20, 2012 at 05:45:40PM +0200, Peter Zijlstra wrote:

quoted

quoted

So, Peter, why does cpuset mangle with cgroup_mutex?  What guarantees
does it need?  Why can't it work on "changed" notification while
caching the current css like blkcg does?

I've no clue sorry.. /me goes stare at this stuff.. Looks like something
Paul Menage did when he created cgroups. I'll have to have a hard look
at all that to untangle this. Not something obvious to me.

Yeah, it would be great if this can be untangled.  I really don't see
any other reasonable way out of this circular locking mess.  If cpuset
needs stable css association across certain period, the RTTD is
caching the css by holding its ref and synchronize modifications to
that cache, rather than synchronizing cgroup operations themselves.

The cgroup core was extracted from cpuset, so they are deeply tangled.

There are several issues to resolve with regard to removing cgroup lock from cpuset.

- there are places that the cgroup hierarchy is travelled. This should be
easy, as cpuset can be made to maintain its hierarchy.

- cpuset disallows clearing cpuset.mems/cpuset.cpus if the cgroup is not empty,
which can be guaranteed only by cgroup lock.

- cpuset disallows a task be attached to a cgroup with empty cpuset.mems/cpuset.cpus,
which again can be guarantted only by cgroup lock.

- cpuset may move tasks from a cgroup to another cgroup (Glauber mentioned this).

- maybe other cases I overlooked..