lkml.org 
[lkml]   [2012]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] cgroup: removing css reference drain wait during cgroup removal
(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


\
 
 \ /
  Last update: 2012-03-13 23:19    [W:0.038 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site