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.<div><br></div><div>First some background:<br><div>
<div><ul><li>cgroups are used to group related processes together and apply resource or scheduling constraints, or policy, to a group as a whole. </li><li>related constraints and policy are themselves collated into "subsystems" (e.g. cpu, memory, etc.)</li>
<li>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</li></ul><div>And an assumption:</div>
<div><ul><li>no init system author, or distribution vendor, can predict how server admins will want to use cgroups</li></ul></div></div><div>The systemd maintainer wrote a proposal for the cgroups tree, you should go read it now: <a href="http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups">Pax Controla Groupiana</a></div>
<div><br></div><div>This is by and large the right thing, this means Upstart should on first startup:</div><div><ul><li>mount a tmpfs on /sys/fs/cgroup</li><li>read a configuration (init.conf?) that specifies the set of hierarchies to create under that</li>
<li>for each hierarchy create the root directory with an appropriate name</li><li>for each hierarchy mount the cgroup filesystem with the config-specified set of subsystems</li><li>for each subsystem in each hierarchy create the subsystem symlink in the top-level and point it at the mount point</li>
<li>for each hierarchy create config-specified sub-directories within the hierarchy</li><li>for each config-specified sub-directory in each hierarchy, set the initial values of the config-specified properties</li></ul></div>
<div>Here's my random thought on config (variables in italibs):</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>begin cgroup <i>projects</i></div><div><i>    </i>subsystem <i>cpuset</i></div>
<div>    subsystem <i>cpu</i></div><div>    subsystem <i>memory</i></div><div><i>    </i>begin group <i>eng</i></div><div><i>        </i>set <i>cpu.shares</i> <i>1024</i></div><div>        set <i>cpuset.mem_exclusive 1</i></div>
<div><i>    </i>end group</div><div>    begin group <i>admin</i></div><div>        set <i>cpu.shares 512</i></div><div><i>    </i>end group</div><div>end cgroup</div></blockquote><div><div><div><br></div><div>Too wordy maybe?</div>
<div><br></div><div>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.</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div><div><div>cgroup <i>projects eng</i></div></div></div></blockquote><div><div><br></div><div>Multiple stanzas would be permitted, and these could be added in sysadmin override files.</div><div><br></div><div>Then a job spawn time, Upstart would place the pid of the job spawned into the appropriate sub-directory within the appropriate cgroup hierarchy.</div>
<div><br></div><div>I think the on-demand creation of sub-directories makes sense if we permit environment variable expansion, e.g.</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>
<div>cgroup <i>upstart</i> $IFACE</div></div></blockquote><div><div><br></div><div>Scott</div><div><div><div>-- <br><div>Have you ever, ever felt like this?</div><div>Had strange things happen?  Are you going round the twist?</div>
<div><br></div><br>
</div></div></div></div>