Hi Tejun, On 2014/4/15 5:44, Tejun Heo wrote: > cgroup users often need a way to determine when a cgroup's > subhierarchy becomes empty so that it can be cleaned up. cgroup > currently provides release_agent for it; unfortunately, this mechanism > is riddled with issues. > > * It delivers events by forking and execing a userland binary > specified as the release_agent. This is a long deprecated method of > notification delivery. It's extremely heavy, slow and cumbersome to > integrate with larger infrastructure. > > * There is single monitoring point at the root. There's no way to > delegate management of subtree. > > * The event isn't recursive. It triggers when a cgroup doesn't have > any tasks or child cgroups. Events for internal nodes trigger only > after all children are removed. This again makes it impossible to > delegate management of subtree. > > * Events are filtered from the kernel side. "notify_on_release" file > is used to subscribe to or suppress release event. This is > unnecessarily complicated and probably done this way because event > delivery itself was expensive. > > This patch implements interface file "cgroup.subtree_populated" which > can be used to monitor whether the cgroup's subhierarchy has tasks in > it or not. Its value is 0 if there is no task in the cgroup and its > descendants; otherwise, 1, and kernfs_notify() notificaiton is > triggers when the value changes, which can be monitored through poll > and [di]notify. > For the old notification mechanism, the path of the cgroup that becomes empty will be passed to the user specified release agent. Like this: # cat /sbin/cpuset_release_agent #!/bin/sh rmdir /dev/cpuset/$1 How do we achieve this using inotify? - monitor all the cgroups, or - monitor all the leaf cgroups, and travel cgrp->parent to delete all empty cgroups. - monitor root cgroup only, and travel the whole hierarchy to find empy cgroups when it gets an fs event. Seems none of them is scalible. > This is a lot ligther and simpler and trivially allows delegating > management of subhierarchy - subhierarchy monitoring can block further > propgation simply by putting itself or another process in the root of > the subhierarchy and monitor events that it's interested in from there > without interfering with monitoring higher in the tree. > > v2: Patch description updated as per Serge. > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
