lkml.org 
[lkml]   [2015]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: cgroup: status-quo and userland efforts
Date
Serge Hallyn <serge.hallyn@...> writes:

>
> Quoting Tim Hockin (thockin@...):

> > > FWIW, the code is too embarassing yet to see daylight, but I'm playing
> > > with a very lowlevel cgroup manager which supports nesting itself.
> > > Access in this POC is low-level ("set freezer.state to THAWED for cgroup
> > > /c1/c2", "Create /c3"), but the key feature is that it can run in two
> > > modes - native mode in which it uses cgroupfs, and child mode where it
> > > talks to a parent manager to make the changes.
> >
> > In this world, are users able to read cgroup files, or do they have to
> > go through a central agent, too?
>
> The agent won't itself do anything to stop access through cgroupfs, but
> the idea would be that cgroupfs would only be mounted in the agent's
> mntns. My hope would be that the libcgroup commands (like cgexec,
> cgcreate, etc) would know to talk to the agent when possible, and users
> would use those.

serge, i realise this is a year on, so you probably have something
at least working by now... but i have a possibly crazy idea..

would it be possible or convenient for the agent that you are writing
to emulate - in userspace - the *exact* same interface as /dev/cgroups,
providing a controlled hierarchy yet presenting itself to other
processes in such a way that its hierarchical management would be
completely transparent to anything that used it?

including of course a new instance of the agent itself, in a recursive
fashion :)

the important question on top of this would be: is there anything that
needs to be atomic which emulation of the /dev/cgroups kernel API in
userspace could not handle?

l.



\
 
 \ /
  Last update: 2015-03-03 23:21    [W:0.214 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site