cgroups in Upstart

Scott James Remnant scott at
Wed May 9 17:01:14 UTC 2012

At the UDS Upstart Roadmap session yesterday I was asked to write down my
original thoughts on how Upstart would handle cgroups on Linux as a guide
to the current maintainers.

First some background:

   - cgroups are used to group related processes together and apply
   resource or scheduling constraints, or policy, to a group as a whole.
   - related constraints and policy are themselves collated into
   "subsystems" (e.g. cpu, memory, etc.)
   - multiple "hierarchies" of cgroup subsystems are permitted, each with
   its own mount of the cgroup filesystem - the set of subsystems that apply
   to the hierarchy is specified at mount time

And an assumption:

   - no init system author, or distribution vendor, can predict how server
   admins will want to use cgroups

The systemd maintainer wrote a proposal for the cgroups tree, you should go
read it now: Pax Controla

This is by and large the right thing, this means Upstart should on first

   - mount a tmpfs on /sys/fs/cgroup
   - read a configuration (init.conf?) that specifies the set of
   hierarchies to create under that
   - for each hierarchy create the root directory with an appropriate name
   - for each hierarchy mount the cgroup filesystem with the
   config-specified set of subsystems
   - for each subsystem in each hierarchy create the subsystem symlink in
   the top-level and point it at the mount point
   - for each hierarchy create config-specified sub-directories within the
   - for each config-specified sub-directory in each hierarchy, set the
   initial values of the config-specified properties

Here's my random thought on config (variables in italibs):

begin cgroup *projects*
*    *subsystem *cpuset*
    subsystem *cpu*
    subsystem *memory*
*    *begin group *eng*
*        *set *cpu.shares* *1024*
        set *cpuset.mem_exclusive 1*
*    *end group
    begin group *admin*
        set *cpu.shares 512*
*    *end group
end cgroup

Too wordy maybe?

For jobs it makes sense to have a "cgroup" stanza that specifies the name
of a cgroup hierarchy and a sub-directory within it. e.g.

cgroup *projects eng*

Multiple stanzas would be permitted, and these could be added in sysadmin
override files.

Then a job spawn time, Upstart would place the pid of the job spawned into
the appropriate sub-directory within the appropriate cgroup hierarchy.

I think the on-demand creation of sub-directories makes sense if we permit
environment variable expansion, e.g.

cgroup *upstart* $IFACE

Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the upstart-devel mailing list