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

[Tejun Heo]

(fixed up mailing list addresses)

On Tue, Mar 13, 2012 at 03:05:51PM -0700, Tejun Heo wrote:
> 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.

Sorry, forgot to reply to the userland-determined object
creation/deletion part.

I don't think there are direct creation cases in sysfs but there are
plenty of deletion going on, especially the kind where a file requests
to delete its parent directly (*/device/delete).  While using
mkdir/rmdir indeed is different for cgroupfs, I don't think that would
make too much of difference.  Both calls are essentially unused by
sysfs currently and there's nothing preventing addition of callbacks
there.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/