cgroups in Upstart
Scott James Remnant
scott at netsplit.com
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*
* *begin group *eng*
* *set *cpu.shares* *1024*
set *cpuset.mem_exclusive 1*
* *end group
begin group *admin*
set *cpu.shares 512*
* *end group
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
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...
More information about the upstart-devel