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?
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
