cgroups in Upstart

[Scott James Remnant]

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
Groupiana<http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups>

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

   - 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
   hierarchy
   - 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


Scott
-- 
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: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20120509/fb006b57/attachment.html>