Re: [systemd-devel] regarding to cgroup siblings mask
On Thu, 09.04.15 14:10, WaLyong Cho (walyong@samsung.com) wrote: In recent systemd(from some month ago), when a unit has a mask for cpu or blockio or memory, this mask is also propagated to siblings by unit_get_target_mask(). According to some of comments, it seems intentional. Could anyone explain why? I added this after talking to Tejun. It's basically what the kernel will effectively do in sane behaviour mode too. Basically, the kernel really wants to avoid having to compare individual processes against groups, because behaviour is unclear then. They want to comapre groups against groups and processes against processes, but not groups against processes, since in many cases behaviour is very unclear then. To avoid the ambighities this creates entirely the answer is to not allow this, and hence always propagate all controller memberships not only towards the root, but also sideways. OK, understood but I'm not sure the compare group properties came under for all of cgroup subsystem. In case of CPUShares=, BlockIOWeight= such like take weight as value, should be. But in case of CPUQuota=, MemoryLimit=, it just a problems of own. Those are not racing with other groups. So for this kind of properties do not need to be propagated to siblings. I'm not sure this make sense. But if yes, below patch will only propagate proportional or relative properties. http://lists.freedesktop.org/archives/systemd-devel/2015-March/029885.html Well, it's a matter of clean design really. Sure, if a controller doesn't have proportional props it's not that important, but it is a much simpler design to disallow processes and cgroups on the same level in the tree, and it's going to be what the sane behaviour cgroup rework of the kernel does... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On Tue, 24.03.15 20:29, WaLyong Cho (walyong@samsung.com) wrote: Hi, In recent systemd(from some month ago), when a unit has a mask for cpu or blockio or memory, this mask is also propagated to siblings by unit_get_target_mask(). According to some of comments, it seems intentional. Could anyone explain why? I added this after talking to Tejun. It's basically what the kernel will effectively do in sane behaviour mode too. Basically, the kernel really wants to avoid having to compare individual processes against groups, because behaviour is unclear then. They want to comapre groups against groups and processes against processes, but not groups against processes, since in many cases behaviour is very unclear then. To avoid the ambighities this creates entirely the answer is to not allow this, and hence always propagate all controller memberships not only towards the root, but also sideways. In our system, some of service have MemoryLimit= options. By this options, all of other services also create its own cgroup in memory. In mobile system(or some of other embedded system), this can be heavy load. If this can be configurable, how about add a configuration for cgroup mask propagation to siblings? The option for this will go away in the kernel too eventually, and we shouldn't intrdouce an option for behaviour we already know now we cannot support for long. I hope this makes some sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On 2015년 04월 09일 01:48, Lennart Poettering wrote: On Tue, 24.03.15 20:29, WaLyong Cho (walyong@samsung.com) wrote: Hi, In recent systemd(from some month ago), when a unit has a mask for cpu or blockio or memory, this mask is also propagated to siblings by unit_get_target_mask(). According to some of comments, it seems intentional. Could anyone explain why? I added this after talking to Tejun. It's basically what the kernel will effectively do in sane behaviour mode too. Basically, the kernel really wants to avoid having to compare individual processes against groups, because behaviour is unclear then. They want to comapre groups against groups and processes against processes, but not groups against processes, since in many cases behaviour is very unclear then. To avoid the ambighities this creates entirely the answer is to not allow this, and hence always propagate all controller memberships not only towards the root, but also sideways. OK, understood but I'm not sure the compare group properties came under for all of cgroup subsystem. In case of CPUShares=, BlockIOWeight= such like take weight as value, should be. But in case of CPUQuota=, MemoryLimit=, it just a problems of own. Those are not racing with other groups. So for this kind of properties do not need to be propagated to siblings. I'm not sure this make sense. But if yes, below patch will only propagate proportional or relative properties. http://lists.freedesktop.org/archives/systemd-devel/2015-March/029885.html Thanks, WaLyong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On Fri, Mar 27, 2015 at 7:56 PM, WaLyong Cho walyong@gmail.com wrote: Hmm, it seems not. When I added MemoryLimit= option to just one service, cgroups for every unit were generated on memory cgroup. It looks like memory_limit and cpu_quota_per_sec_usec both have this potential issue. The other four controllers managed this way are clearly proportional (using weights or shares). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On 03/31/2015 05:13 AM, David Timothy Strauss wrote: On Fri, Mar 27, 2015 at 7:56 PM, WaLyong Cho walyong@gmail.com wrote: Hmm, it seems not. When I added MemoryLimit= option to just one service, cgroups for every unit were generated on memory cgroup. It looks like memory_limit and cpu_quota_per_sec_usec both have this potential issue. The other four controllers managed this way are clearly proportional (using weights or shares). Then, is this patch able to be a solution? http://lists.freedesktop.org/archives/systemd-devel/2015-March/029885.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On 03/28/2015 09:25 AM, David Timothy Strauss wrote: On Thu, Mar 26, 2015 at 7:33 PM, WaLyong Cho walyong@samsung.com wrote: Thanks, understood. But I think this propagation is needed only for taking weight argument such like CPUShares=weight, StartupCPUShares=weight, BlockIOWeight=weight, StartupBlockIOWeight=weight, BlockIODeviceWeight=device weight. For example, I don't think MemoryLimit= is not option of proportional. It just only limit of its cgroup and does not race with other cgroup. If I'm right, we need to modify unit_get_target_mask() to get only mask for proportional properties. I'm pretty sure we already do that. If not, it's a bug. Hmm, it seems not. When I added MemoryLimit= option to just one service, cgroups for every unit were generated on memory cgroup. ___ 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] regarding to cgroup siblings mask
On Thu, Mar 26, 2015 at 7:33 PM, WaLyong Cho walyong@samsung.com wrote: Thanks, understood. But I think this propagation is needed only for taking weight argument such like CPUShares=weight, StartupCPUShares=weight, BlockIOWeight=weight, StartupBlockIOWeight=weight, BlockIODeviceWeight=device weight. For example, I don't think MemoryLimit= is not option of proportional. It just only limit of its cgroup and does not race with other cgroup. If I'm right, we need to modify unit_get_target_mask() to get only mask for proportional properties. I'm pretty sure we already do that. If not, it's a bug. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On 03/27/2015 05:33 AM, David Timothy Strauss wrote: On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho walyong@samsung.com wrote: Could anyone explain why? An admin using CPUShares= or a similar proportional CGroup controller probably assumes that setting the shares to twice the default (for example) increases the relative proportion of resources for that unit. However, that is only true if other units competing for that resource have the same controller(s) enabled so that the kernel knows to balance the resources accordingly. The code in systemd ensures that if any unit uses a proportional CGroups controller in a slice, all other units in that same slice enable that controller as well, usually with the default proportions. Thanks, understood. But I think this propagation is needed only for taking weight argument such like CPUShares=weight, StartupCPUShares=weight, BlockIOWeight=weight, StartupBlockIOWeight=weight, BlockIODeviceWeight=device weight. For example, I don't think MemoryLimit= is not option of proportional. It just only limit of its cgroup and does not race with other cgroup. If I'm right, we need to modify unit_get_target_mask() to get only mask for proportional properties. unit_get_target_mask() is part of an optimization I added so that initializing CGroups controllers for a given unit doesn't require iterating through every other unit in a slice to figure out the necessary controllers. It provides a bitmask indicating the controllers in use by its siblings so the unit can enable, say, CPUShares= if one of its siblings is doing so. ___ 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] regarding to cgroup siblings mask
On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho walyong@samsung.com wrote: If this can be configurable, how about add a configuration for cgroup mask propagation to siblings? I believe the way to prevent propagation is to separate the units into different slices. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho walyong@samsung.com wrote: Could anyone explain why? An admin using CPUShares= or a similar proportional CGroup controller probably assumes that setting the shares to twice the default (for example) increases the relative proportion of resources for that unit. However, that is only true if other units competing for that resource have the same controller(s) enabled so that the kernel knows to balance the resources accordingly. The code in systemd ensures that if any unit uses a proportional CGroups controller in a slice, all other units in that same slice enable that controller as well, usually with the default proportions. unit_get_target_mask() is part of an optimization I added so that initializing CGroups controllers for a given unit doesn't require iterating through every other unit in a slice to figure out the necessary controllers. It provides a bitmask indicating the controllers in use by its siblings so the unit can enable, say, CPUShares= if one of its siblings is doing so. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] regarding to cgroup siblings mask
Hi, In recent systemd(from some month ago), when a unit has a mask for cpu or blockio or memory, this mask is also propagated to siblings by unit_get_target_mask(). According to some of comments, it seems intentional. Could anyone explain why? In our system, some of service have MemoryLimit= options. By this options, all of other services also create its own cgroup in memory. In mobile system(or some of other embedded system), this can be heavy load. If this can be configurable, how about add a configuration for cgroup mask propagation to siblings? Thanks, WaLyong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
