[systemd-devel] [HEADSUP] cgroup changes

Lennart Poettering lennart at poettering.net
Tue Jul 16 17:43:00 PDT 2013


On Tue, 25.06.13 08:31, Brian Bockelman (bbockelm at cse.unl.edu) wrote:

> 
> On Jun 25, 2013, at 4:56 AM, Lennart Poettering <lennart at poettering.net> wrote:
> 
> > On Tue, 25.06.13 02:21, Brian Bockelman (bbockelm at cse.unl.edu) wrote:
> > 
> >> A few questions came to mind which may provide interesting input 
> >> to your design process:
> >> 1) I use cgroups heavily for resource accounting.  Do you envision 
> >>  me querying via dbus for each accounting attribute?  Or do you 
> >>  envision me querying for the cgroup name, then accessing the 
> >> controller statistics directly?
> > 
> > Good question. Tejun wants systemd to cover that too. I am not entirely
> > sure. I don't like the extra roundtrip for measuring the accounting
> > bits. But maybe we can add a library that avoids the roundtrip, and
> > simply provides you with high-level accounting values for cgroups. That
> > way, for *changing* things you'd need to go via the bus, for *reading*
> > things we'd give you a library that goes directly to the cgroupfs and
> > avoids the roundtrip.
> 
> I like this idea.  Hopefully single-writer, multiple-reader is more sustainable path forward.
> 
> What about the notification APIs?  We currently use the
> memory.oom_control to get a notification when a job hits limits (this
> allows us to know the job died due to memory issues, as the user code
> itself typically just SIGSEGV's).  Is subscribing to notifications
> considered reading or writing in this case?

That sounds like another case for the library, i.e. is more considered
reading. That said I think the current notification infrastructure of
cgroup attributes is really really awful, so I am not to keen to support
that right-away.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list