Re: [RFC] cgroup: removing css reference drain wait during cgroup removal

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

Hey, Matt.

On Tue, Mar 13, 2012 at 02:45:26PM -0700, Matt Helsley wrote:
> If you want to spend your time doing archaeology there are some old threads
> that touch on this idea (roughly around 2003-2005). One point against the
> idea that I distinctly recall:
> 
> Somewhat like configfs, object lifetimes in cgroups are determined
> primarily by the user whereas sysfs object lifetimes are primarily
> determined by the kernel. I think the closest we come to user-determined
> objects in sysfs occur through debugfs, and module loading/unloading.
> However those involve mount/umount and modprobe/rmmod rather than
> mkdir/rmdir to create and remove the objects.

The thing is that sysfs itself has been almost completely rewritten
since that time to 1. decouple internal representation from vfs
objects and 2. provide proper isolation between the userland and
kernel code exposing data through sysfs.

#1 began mostly due to the large size of dentries and inodes but, with
the benefit of hindsight, I think it just was a bad idea to piggyback
on vfs objects for object life-cycle management and locking for stuff
which is wholely described in memory with simplistic locking.

#2 was necessary to avoid hanging device detach due to open sysfs file
from userland.  sysfs now has notion of "active access" encompassing
only each show/store op invocation and it only guarantees that the
associated device doesn't go away while active accesses are in
progress.

The sysfs heritage is almost recognizable and unfortunately almost the
same set of problems (nobody wants show/store ops to be called on
unlinked css waiting for references to be drained).  As refactoring
and sharing sysfs won't be a trivial task, my plan is to first augment
cgroupfs as necessary with longer term goal of converging and later
sharing the same code with sysfs.

Thanks.

-- 
tejun