Re: [systemd-devel] Where did DefaultControllers= option go?
Am 29.10.2013 17:52, schrieb Kay Sievers: >> None of this explains why systemd no longer applies certain controllers >> by default. Previously, systemd would attach cpu controllers to each >> service by default. Now, it only groups your processes in the systemd >> tree, but does not touch any cgroup controllers. >> >> The new default behaviour (or lack thereof) seems like a step back to me. > > It's a property of a unit now which cgroup controllers get attached: > > http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html > > The global mirroring across trees makes no sense in the future. The > several independent trees will go away in the kernel next year, and > then systemd would not know what to do with an instruction like > DefaultControllers. I realized that when I set the CPUShares attribute on any unit, systemd mirrors the whole cgroup tree into the cpu,cpuacct tree. However, in the past, it was mirrored regardless of such setting. This had the benefit that CPU was equally distributed among services, not among processes. That benefit is now gone if I choose to not configure any cpu settings. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 6:56 PM, Kay Sievers wrote: > On Tue, Oct 29, 2013 at 6:45 PM, Umut Tezduyar wrote: > >>> The global mirroring across trees makes no sense in the future. The >>> several independent trees will go away in the kernel next year, and >>> then systemd would not know what to do with an instruction like >>> DefaultControllers. >> >> I don't disagree that mirroring will not make sense in the future. >> Though, without global mirroring on cpuacct I don't understand how >> systemd-cgtop is expected to give cpu accounting information of >> individual services. Also without global mirroring on cpu control >> group, how would CPUShares=weight even work on any service. I am just >> confused. > > The kernel will only have one single hierarchy, all properties will be > located in this single tree. Thats great but all in the future as you are also saying. > > Cgtop just reads the stuff from the controller *attributes* there, > instead of finding them in a separate controller *tree*. Actually, cgtop just reads the stuff from the cpuacct controller's hierarchy as of today and thats why it is not working for me. Thank you for your email but I think my confusion still remains. Umut > > Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 6:45 PM, Umut Tezduyar wrote: >> The global mirroring across trees makes no sense in the future. The >> several independent trees will go away in the kernel next year, and >> then systemd would not know what to do with an instruction like >> DefaultControllers. > > I don't disagree that mirroring will not make sense in the future. > Though, without global mirroring on cpuacct I don't understand how > systemd-cgtop is expected to give cpu accounting information of > individual services. Also without global mirroring on cpu control > group, how would CPUShares=weight even work on any service. I am just > confused. The kernel will only have one single hierarchy, all properties will be located in this single tree. Cgtop just reads the stuff from the controller *attributes* there, instead of finding them in a separate controller *tree*. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 5:52 PM, Kay Sievers wrote: > On Tue, Oct 29, 2013 at 5:39 PM, Thomas Bächler wrote: >> Am 29.10.2013 17:21, schrieb Colin Guthrie: > >>> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: I have noticed DefaultControllers= option is no longer in system.conf file. Has it been moved to somewhere else or are all controllers default controllers by default? >>> >>> See the various posts on this list and in blogs regarding the cgroups >>> rework. In particular see the mails with the subject "[HEADSUP] cgroup..." >>> >>> See also: >>> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ >> >> None of this explains why systemd no longer applies certain controllers >> by default. Previously, systemd would attach cpu controllers to each >> service by default. Now, it only groups your processes in the systemd >> tree, but does not touch any cgroup controllers. >> >> The new default behaviour (or lack thereof) seems like a step back to me. > > It's a property of a unit now which cgroup controllers get attached: > > http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html > > The global mirroring across trees makes no sense in the future. The > several independent trees will go away in the kernel next year, and > then systemd would not know what to do with an instruction like > DefaultControllers. I don't disagree that mirroring will not make sense in the future. Though, without global mirroring on cpuacct I don't understand how systemd-cgtop is expected to give cpu accounting information of individual services. Also without global mirroring on cpu control group, how would CPUShares=weight even work on any service. I am just confused. Umut > > All implementation details of kernel cgroups are no longer exposed in > systemd, which is a huge step forward, not back. > > Kay > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 5:39 PM, Thomas Bächler wrote: > Am 29.10.2013 17:21, schrieb Colin Guthrie: >> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: >>> I have noticed DefaultControllers= option is no longer in system.conf >>> file. Has it been moved to somewhere else or are all controllers >>> default controllers by default? >> >> See the various posts on this list and in blogs regarding the cgroups >> rework. In particular see the mails with the subject "[HEADSUP] cgroup..." >> >> See also: >> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > None of this explains why systemd no longer applies certain controllers > by default. Previously, systemd would attach cpu controllers to each > service by default. Now, it only groups your processes in the systemd > tree, but does not touch any cgroup controllers. > > The new default behaviour (or lack thereof) seems like a step back to me. It's a property of a unit now which cgroup controllers get attached: http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html The global mirroring across trees makes no sense in the future. The several independent trees will go away in the kernel next year, and then systemd would not know what to do with an instruction like DefaultControllers. All implementation details of kernel cgroups are no longer exposed in systemd, which is a huge step forward, not back. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
'Twas brillig, and Thomas Bächler at 29/10/13 16:39 did gyre and gimble: > Am 29.10.2013 17:21, schrieb Colin Guthrie: >> Hi, >> >> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: >>> I have noticed DefaultControllers= option is no longer in system.conf >>> file. Has it been moved to somewhere else or are all controllers >>> default controllers by default? >> >> See the various posts on this list and in blogs regarding the cgroups >> rework. In particular see the mails with the subject "[HEADSUP] cgroup..." >> >> See also: >> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > None of this explains why systemd no longer applies certain controllers > by default. Previously, systemd would attach cpu controllers to each > service by default. Now, it only groups your processes in the systemd > tree, but does not touch any cgroup controllers. I can't remember the details but I'm sure there was an explanation posted at some point. I'll let Lennart or Tejun explain the details. I think it relates to the CPUAccounting, MemoryAccounting and BlockIOAccounting settings detailed in systemd.resource-control(5) In addition, if clarifications are added to the previously provided URL, http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ should likely be updated (used to be referenced in man pages but was dropped in 7ac807320a7416463d7ff3ef6ede574863a601c5 although the wiki page itself still exists obviously) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
Am 29.10.2013 17:21, schrieb Colin Guthrie: > Hi, > > 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: >> I have noticed DefaultControllers= option is no longer in system.conf >> file. Has it been moved to somewhere else or are all controllers >> default controllers by default? > > See the various posts on this list and in blogs regarding the cgroups > rework. In particular see the mails with the subject "[HEADSUP] cgroup..." > > See also: > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ None of this explains why systemd no longer applies certain controllers by default. Previously, systemd would attach cpu controllers to each service by default. Now, it only groups your processes in the systemd tree, but does not touch any cgroup controllers. The new default behaviour (or lack thereof) seems like a step back to me. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
Hi, 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: > I have noticed DefaultControllers= option is no longer in system.conf > file. Has it been moved to somewhere else or are all controllers > default controllers by default? See the various posts on this list and in blogs regarding the cgroups rework. In particular see the mails with the subject "[HEADSUP] cgroup..." See also: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Where did DefaultControllers= option go?
Hi, I have noticed DefaultControllers= option is no longer in system.conf file. Has it been moved to somewhere else or are all controllers default controllers by default? If all the controllers are default controllers then something is weird. I have both cpu and cpuacct controllers (and they are joined by systemd) but they don't have system.slice in it (basically they are not mirrored). What could it be? Kernel: 3.10 Impact, systemd-cgtop doesn't work, cpu resource allocation doesn't work, etc. ls -al /sys/fs/cgroup/cpu,cpuacct/ -rw-r--r--1 root root 0 Feb 1 01:15 cgroup.clone_children --w--w--w-1 root root 0 Feb 1 01:15 cgroup.event_control -rw-r--r--1 root root 0 Feb 1 01:29 cgroup.procs -r--r--r--1 root root 0 Feb 1 01:15 cgroup.sane_behavior -rw-r--r--1 root root 0 Feb 1 01:15 cpu.shares -r--r--r--1 root root 0 Feb 1 01:15 cpuacct.stat -rw-r--r--1 root root 0 Feb 1 01:15 cpuacct.usage -r--r--r--1 root root 0 Feb 1 01:15 cpuacct.usage_percpu -rw-r--r--1 root root 0 Feb 1 01:15 notify_on_release -rw-r--r--1 root root 0 Feb 1 01:15 release_agent -rw-r--r--1 root root 0 Feb 1 01:15 tasks ls -al /sys/fs/cgroup/systemd/ -rw-r--r--1 root root 0 Feb 1 01:15 cgroup.clone_children --w--w--w-1 root root 0 Feb 1 01:15 cgroup.event_control -rw-r--r--1 root root 0 Feb 1 01:15 cgroup.procs -r--r--r--1 root root 0 Feb 1 01:15 cgroup.sane_behavior -rw-r--r--1 root root 0 Feb 1 01:15 notify_on_release -rw-r--r--1 root root 0 Feb 1 01:15 release_agent drwxr-xr-x 54 root root 0 Feb 1 01:17 system.slice -rw-r--r--1 root root 0 Feb 1 01:15 tasks Note, I have checked it on arch with latest systemd and it is not mirrored there either. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
