#StackBounty: #systemd #cgroups #cpu-usage What's "broken" about cpuset cgroup inheritance semantics in the Linux kernel?

Bounty: 150

To quote the 2013 systemd announcement of the new control group interface (with emphasis added):

Note that the number of cgroup attributes currently exposed as unit properties is limited. This will be extended later on, as their kernel interfaces are cleaned up. For example cpuset or freezer are currently not exposed at all due to the broken inheritance semantics of the kernel logic. Also, migrating units to a different slice at runtime is not supported (i.e. altering the Slice= property for running units) as the kernel currently lacks atomic cgroup subtree moves.

So, what’s broken about the inheritance semantics of the kernel logic for cpuset (and how does this brokenness not apply to other cgroup controllers such as cpu)?

There is an article on RedHat’s website giving an unverified solution for how to use cgroup cpusets in RHEL 7 despite their lack of support as easy-to-manage systemd unit properties…but is this even a good idea? The bolded quotation above is concerning.

To put it another way, what are the “gotchas” (pitfalls) that could apply to using cgroup v1 cpuset which are being referenced here?

I’m starting a bounty on this.

Possible sources of information to answer this question (in no special order) include:

  1. cgroup v1 documentation;
  2. kernel source code;
  3. test results;
  4. real-world experience.

One possible meaning of the bolded line in the quote above would be that when a new process is forked it does not stay in the same cpuset cgroup as its parent, or that it is in the same cgroup but in some sort of “unenforced” status whereby it may actually be running on a different CPU than the cgroup allows. However, this is pure speculation on my part and I need a definitive answer.

Get this bounty!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.