Skip to content

core: make settings for unified cgroup hierarchy supersede the ones f…#4269

Merged
keszybz merged 1 commit intosystemd:masterfrom
htejun:cgroup-update-config-translation
Oct 15, 2016
Merged

core: make settings for unified cgroup hierarchy supersede the ones f…#4269
keszybz merged 1 commit intosystemd:masterfrom
htejun:cgroup-update-config-translation

Conversation

@htejun
Copy link
Contributor

@htejun htejun commented Oct 2, 2016

…or legacy hierarchy

There are overlapping control group resource settings for the unified and
legacy hierarchies. To help transition, the settings are translated back and
forth. When both versions of a given setting are present, the one matching the
cgroup hierarchy type in use is used. Unfortunately, this is more confusing to
use and document than necessary because there is no clear static precedence.

Update the translation logic so that the settings for the unified hierarchy are
always preferred. systemd.resource-control man page is updated to reflect the
change and reorganized so that the deprecated settings are at the end in its
own section.

@evverx
Copy link
Contributor

evverx commented Oct 3, 2016

@htejun , thanks!

I'm rereading #4096
How should we handle

MemoryMax=...
MemorySwapMax=...

if the legacy control group hierarchy is used?

@htejun
Copy link
Contributor Author

htejun commented Oct 3, 2016

So, if either MemoryMax or MemorySwapMax is specified, the MemoryMax value (whether that's the default unlimited value or not) should be used. If neither is used, MemoryLimit is used. This should address #4096, right?

@evverx
Copy link
Contributor

evverx commented Oct 3, 2016

cc @walyong

Copy link
Member

@keszybz keszybz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we should do this. It doesn't preclude anyone from using the legacy hierarchy like before, but makes the preference for v2 clear, and actually simplifies things for people who are trying to support both.

Apart from a few c&p issues, looks great.

<para>Implies <literal>CPUAccounting=true</literal>.</para>

<para>These settings are supported only if the legacy control group hierarchy is used.</para>
<para>These settings replace <varname>CPUShares=</varname> and <varname>StartupCPUWeight=</varname>.</para>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"and StartupCPUShares"

<para>This setting is supported only if the unified control group hierarchy is used. Use
<varname>BlockIOAccounting=</varname> on systems using the legacy control group hierarchy.</para>
<para>This setting replaces <varname>BlockIOAccounting=</varname> and disables <varname>BlockIO</varname>
prefixed settings.</para>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BlockIO and StartupBlockIO -prefixed. Or maybe it'd be better to just list them.

<varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname> on systems using the legacy
control group hierarchy.</para>
<para>These settings replace <varname>BlockIOWeight=</varname> and <varname>StartupBlockIOWeight=</varname>
and disable <varname>BlockIO</varname> prefixed settings.</para>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly here.

<para>This setting is supported only if the unified control group hierarchy is used. Use
<varname>BlockIODeviceWeight=</varname> on systems using the legacy control group hierarchy.</para>
<para>This setting replaces <varname>BlockIODeviceWeight=</varname> and disables <varname>BlockIO</varname>
prefixed settings.</para>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... and here.

LIST_FOREACH_SAFE(device_bandwidths, b, next, c->blockio_device_bandwidths) {
if (!cgroup_apply_blkio_device_limit(u, b->path, b->rbps, b->wbps))
cgroup_context_free_blockio_device_bandwidth(c, b);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for {} here.

log_cgroup_compat(u, "Applying MemoryMax %" PRIi64 " as MemoryLimit", val);
} else {
val = c->memory_limit;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No {} here please.

@keszybz keszybz added this to the v232 milestone Oct 10, 2016
@poettering
Copy link
Member

lgtm, besides the things @keszybz already pointed out

@poettering poettering added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Oct 11, 2016
…or legacy hierarchy

There are overlapping control group resource settings for the unified and
legacy hierarchies.  To help transition, the settings are translated back and
forth.  When both versions of a given setting are present, the one matching the
cgroup hierarchy type in use is used.  Unfortunately, this is more confusing to
use and document than necessary because there is no clear static precedence.

Update the translation logic so that the settings for the unified hierarchy are
always preferred.  systemd.resource-control man page is updated to reflect the
change and reorganized so that the deprecated settings are at the end in its
own section.
@htejun htejun force-pushed the cgroup-update-config-translation branch from ff4c9f8 to 3fe2c30 Compare October 14, 2016 13:23
@htejun
Copy link
Contributor Author

htejun commented Oct 14, 2016

Updated as per @keszybz's comments.

@keszybz keszybz removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Oct 14, 2016
@keszybz keszybz merged commit 7d862ab into systemd:master Oct 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

4 participants