[v1.3.2/v1.4.0-rc.1 intentional change] `cpu.weight` value changed

[AkihiroSuda]

Description

The cpu.weight value below has changed in runc v1.4.0-rc.1

v1.3.1

$ sudo nerdctl run --rm --cpu-shares 2000 busybox cat /sys/fs/cgroup/cpu.weight
77

v1.4.0-rc.1

$ sudo nerdctl run --rm --cpu-shares 2000 busybox cat /sys/fs/cgroup/cpu.weight
170

Steps to reproduce the issue

sudo nerdctl run --rm --cpu-shares 2000 busybox cat /sys/fs/cgroup/cpu.weight

Describe the results you received and expected

Received: 170
Expected: 77

What version of runc are you using?

runc version 1.4.0-rc.1
commit: v1.4.0-rc.1-0-gb2ec7f92
spec: 1.2.1+dev
go: go1.24.6
libseccomp: 2.5.5

Host OS information

PRETTY_NAME="Ubuntu 25.04"

Host kernel information

Linux vmubuntu 6.14.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Aug 7 18:15:08 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

[AkihiroSuda]

Caused in:

• deps: bump cgroups to v0.0.3, fix a few regressions #4785

Maybe this was an intentional change:

• Conversion of cgroup v1 CPU shares to v2 CPU weight causes workloads to have low CPU priority #4772

[cyphar]

Yeah this was an intentional change, IIRC our old behaviour was wrong -- kubernetes/kubernetes#131216 is the Kubernetes issue about the topic.

For what it's worth, this is an even stronger argument that we need to include CHANGELOG.md diffs in the patch which implements the feature, because I forgot about this change when reviewing the changelog (especially now that our cgroup code is in a separate repo and so you can't see the commit messages when reviewing the git log).

[kolyshkin]

And now we are bringing the same change to v1.3.2 (#4897, #4906). Yes, it is a breaking change (mostly for tests I guess), but this is a correct change as the new weights are better aligned to cgroup v2 defaults (we have discussed it back and forth with @giuseppe and other stakeholders -- see kubernetes/kubernetes#131216 (comment) and further comments).

The gist of it is we needed a v1 -> v2 conversion formula which:

1. converts min v1 value to min v2 value (2 -> 1);
2. converts max v1value to max v2 value (262144 -> 10000);
3. converts the default v1 value to defalt v2 value (1024 -> 100);

The old one did only did 1 and 2. The new one does 3.

[cyphar]

I'm not sure I agree with it being a "breaking change". Bugfixes -- by definition -- change behaviour in ways that can be detected by users, but not every bugfix is a breaking change.

I see this as a bugfix that should've been called out properly in the changelog (and we should improve our changelog policy for future runc versions -- I'll open a PR to update the contributing docs and add a CI job).

[kolyshkin]

Removed this from the 1.4.0-rc.2 milestone as there's nothing we will do about it. If that's a reminder about the changelog, we already have this in v1.3.2 one.

Let's keep the issue open for some time for visibility (I'm going to also pin it).