On Fri, Jun 21, 2013 at 1:10 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Fri, 21.06.13 12:59, Kok, Auke-jan H (auke-jan.h....@intel.com) wrote: > >> > http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html >> > >> > Here's an update and a bit on the bigger picture: >> >> Thanks for doing this - I am really looking forward to seeing this all >> take shape, and I hope to be able to leverage this in the future :^) >> >> All the points below are great, and problems that I've encountered in >> the past have all hinted towards this being the right way forward. >> >> #2 below has my interest - when you have some ideas about how the API >> will look I'd like to review it and match against our use cases... > > Point #2 is precisely about not having APIs for this... ;-) > > 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? Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
