http://bugzilla.suse.com/show_bug.cgi?id=954765
http://bugzilla.suse.com/show_bug.cgi?id=954765#c7
--- Comment #7 from Franck Bui
(In reply to Franck Bui from comment #5)
(In reply to Mel Gorman from comment #4)
It is possible this was an oversight. I do not have the full picture of what was planned but it appears that the intent was to activate this only for new containers. It's just the case that in Tumbleweed that normal sessions (or at least ssh sessions from root) are also impacted. If only processes within a container or a VM were resource controlled then it would limit the impact of this bug.
I think the intent was to really activate this for 'root' user sessions too. Regular user sessions are left alone for now unless unified hierarchy is supported and used by the kernel.
This means that any process launched by root be it manual launch of a server or a benchmark is going to be throttled. It cannot be what they really intended or if they did, it's a massive overhead to occur for very little, if any, gain.
See commit which introduced the Delegate property for some details: https://github.com/systemd/systemd/commit/ a931ad47a8623163a29d898224d8a8c1177ffdaf
The commit to me seems to say that it was only intended to be activated for containers :(
From the commit message:
"Delegate=yes should also be set for user@.service, so that systemd --user can run, controlling its own cgroup tree." user@.service also handles root user session (in that case it's named 'user@0.service) and this unit is a priviliged one when executed for root user. And still from the commit message: "For priviliged units this resource control property ensures that the processes have all controllers systemd manages enabled." -- You are receiving this mail because: You are on the CC list for the bug.