Thread-level control with resource groups

k8to — Wed, 16 Mar 2016 20:54:36 +0000

One part of the disagreement here is programs making use of control groups vs the administrator doing so. Or in some cases the distribution's default behavior, which is influenced by the administrator.

I have to say this is incredibly murky at hte moment, with the various patterns of use that have been in play since control groups were introduced. Some systems may have an optional management interface, some systems may expect SystemD to be the point of control for control groups. All of it is sort of half-documented.

I work on a program that manages its own children, lots of them. I'd like to use kernel features to limit the memory these children can use individually and collectively, if possible. Control Groups can do this, but the path to a safe implementation that will work with the system as deployed and will not interfere with the administrator isn't clear at all. One escape hatch I have, of course, is the ability to let the application administrator turn off all cgroup functionality within the program if he or she wants to control it via other means. But I really need the software to do this by default as the vast majority of the people using the software aren't clever enough to know what a control group is.

LWN: Comments on "Thread-level control with resource groups"

Thread-level control with resource groups