On Fri, 21.06.13 14:10, Kok, Auke-jan H (auke-jan.h....@intel.com) wrote: > > So, in the future, when you have some service, and that service wants to > > alter some cgroup resource limits for itself (let's say: set its own cpu > > shares value to 1500), this is what should happen: the service should > > use a call like sd_pid_get_unit() to get its own unit name, and then use > > dbus to invoke SetCPUShares(1500) for that service. systemd will then do > > the rest. (*) > > > > Lennart > > > > (*) to make this even simpler we have been thinking of defining a new > > "virtual" bus object path /org/freedesktop/systemd1/self/ or so which > > will always points to the callers own unit. This would be similar to > > /proc/self/ which also points to its own PID dir for each > > process... With that in place you could then set any resource setting > > you want with a single bus method call. > > This is fine for applications that manage themselves, but I'm seeing > more interest in use cases where we want external influence on cgroup > hierarchies, for instance: > > - foreground/background priorities - a window manager marks background > applications and puts them in the freezer, changes oom_score_adj so > that old apps can get automatically cleaned up in case memory > availability is low. > - detecting runaway apps and taking cpu slices away from them. > - thermally constraining classes of applications > > Those would be tasks that an external process would do by manipulating > properties of cgroups, not something each task would do on it's own. > > Do you suggest these manipulations should be implemented without high > level systemd API's and the "controller" just manipulates the cgroups > directly?
All changes to cgroup attributes must go through systemd. If the WM wants to freeze or adjust OOM he needs to issue systemd bus calls for that. The run-away stuff I can't follow? the kernel will distribute CPU evenly among running apps if all want it, so not seeing why there's more monitoring needed. The thermal stuff is probably best done in-kernel i guess... Too dangerous/subject-to-latency for userspace, no? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
