On Wed, Feb 14, 2018 at 3:06 AM, Josh Snyder <jo...@netflix.com> wrote:
> Hi all, > > I'm working on a use-case where I want to impose memory limits on the > system in > aggregate, with one process (e.g. memcached) opted-out of the limit. With a > typical distribution's setup (Ubuntu, in my case), I would be able to > impose a > memory limit on each systemd slice (viz. user, machine, system) > separately, but > not in aggregate. > > I've found a solution for this by launching systemd in a cgroup of its > own. In > the initramfs, I have a script (snippet included below) which mounts the > cgroupfs, puts all of the extant processes into a new cgroup, and then > umounts > the cgroupfs. > > This works for my needs: all of the processes in the system live in one > cgroup, > except memcached in a separate cgroup. systemd seems perfectly happy to > boot in > this configuration, correctly sensing that it's operating in a cgroup and > nesting the processes it is responsible for under the existing cgroup. With > memcached running separately, the resulting hierarchy looks like: > > /sys/fs/cgroup/ > ├── memcached > └── root > ├── init.scope > ├── system.slice > ... > > And /proc/1/cgroup shows that the systemd (and more importantly, its > descendants) lives in the memory cgroup: > > 11:net_cls,net_prio:/ > 10:cpuset:/ > 9:freezer:/ > 8:hugetlb:/ > 7:perf_event:/ > 6:pids:/root/init.scope > 5:devices:/root/init.scope > 4:cpu,cpuacct:/ > 3:blkio:/ > 2:memory:/root > 1:name=systemd:/root/init.scope > > I've tested against both legacy and unified cgroup hierarchies. The > functionality to detect the current cgroups and nest processes underneath > them > appears to be in manager_setup_cgroup (src/core/cgroup.c:2033). My > question for > the list is what motivated adding this awesome feature to systemd in the > first > place, and (more importantly to me) is it likely to continue to exist in > the > future? > I'm assuming it happens to work because the unprivileged `systemd --user` instances require the same kind of autodetection. -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel