[cgmanager-devel] [RFC] cgroup cleanup

[Serge Hallyn]

Hi

currently cgmanager doesn't do any cgroup cleanup itself.  It provides
the Remove dbus method for programs to do so themselves.  There are
a few options for improving on this.

Background: while Tejun intends to implement a new and improved kernel
method for cleaning up cgroups, currently the only way to have this
done automatically is using release-agent and notify-on-release.  You
echo the path of a program into release-agent, which will then get
called when any cgroup for which notify-on-release is set to 1 which
becomes empty.

I've been putzing on what to do with this because there may well be
cases where caller wants the cgroups to stay around after they become
empty, yet I didn't particularly want a new API call to say "let
this cgroup be auto-pruned.  Such a new api call doesn't really help
us unless userspace is judicious in using it when needed, and if they
will do that they can just as well do the cleanup.

So I see a few possibilities:

X
We can just always remove any cgroups which become empty.  Userspace
can always recreate if need be.  However, I do personally create
cgroups, i.e. for freezing builds when my laptop gets hot, which
become empty and are later re-used.  If we assume that users can
always recreate those on demand without having to become root, then it's
not such a big deal.

X
Or, we can make notify-on-release=1 be the default for all cgroups, and
provide an API call to request that cleanup not be done automatically.

X
The third is more ambitious.  cgmanager sets the release-agent to be a
program which writes the names of deleted cgroups to a file.
Whenever cgmanager creates a directory, it logs path alongside the inode
number of the requestor's namespace.  Every N seconds it yanks in the
list of deleted paths from the release-agents, adds it to the list in
memory, and then goes through and checks whether the requestor's
namespace still exists.  If not, it deletes it.

In the case of nested containers this lazily does what we want, as
/lxc/c1/lxc/c2 will be removed when c1 is destroyed.  On the other hand,
unless we cache information on the requesting task itself, requestors
on the host will never be cleaned up.

X
Another is to interpret 'Chown' as a delegation.  Any time a cgroup
is chowned, we mark it as notify-on-release.  Typically a chown will
be done for a login session or a container start.  When one of those
becomes empty, it is typically to be discarded.

Any other ideas?

thanks,
-serge