Handle kmem.limit_in_bytes removal

[jrife]

kmem.limit_in_bytes has been removed in upstream linux and this patch is queued to be backported to linux 6.1 stable:

• https://lore.kernel.org/linux-mm/[email protected]/T/
• https://www.spinics.net/lists/stable-commits/msg316619.html

Without this change to libcontainerd, GetStats() will return an error on the latest kernel(s). A downstream effect is that Kubernetes's kubelet does not start up. This fix was tested by ensuring that it unblocks kubelet startup when running on the latest kernel.

[AkihiroSuda]

This fix was tested by ensuring that it unblocks kubelet startup when running on the latest kernel.

On what distro?
Why is that distro still using cgroup v1 with the latest kernel?

[jrife]

This fix was tested by ensuring that it unblocks kubelet startup when running on the latest kernel.

On what distro? Why is that distro still using cgroup v1 with the latest kernel?

I was doing some testing with the latest kernel when I noticed this issue with cgroups v1. The kernel config may have not enabled v2. The base OS was Ubuntu 20.04.2 LTS.

[thaJeztah]

somewhat orthogonal, but reminds me of this ticket I opened at the time;

• Should memory.kmem.tcp.limit_in_bytes still be supported? #3174

[thaJeztah]

Oh! And I just see the latest comments on that ticket that I somehow missed 🙈 (so ignore my earlier comment)

[kolyshkin]

I need to do some experimenting first, but I think that if the kmem.limit_in_bytes is not set, then the kernel memory accounting is turned off, and thus kmem.{usage_in_bytes,max_usage_in_bytes,failcnt} all return 0 anyway.

Thus, it does not make sense to read those, and we can simply return a bunch of 0 in stats.MemoryStats.KernelUsage.

[jepio]

This fix was tested by ensuring that it unblocks kubelet startup when running on the latest kernel.

On what distro? Why is that distro still using cgroup v1 with the latest kernel?

Flatcar Container Linux. There is still a large pool of users that want to continue running cgroup v1.

We continue supporting both cgroup v1 and cgroup v2. We are currently updating to kernel v6.1.54, and kubelet doesn't start anymore in the cgroup v1 configuration.

[jepio]

I need to do some experimenting first, but I think that if the kmem.limit_in_bytes is not set, then the kernel memory accounting is turned off, and thus kmem.{usage_in_bytes,max_usage_in_bytes,failcnt} all return 0 anyway.

Thus, it does not make sense to read those, and we can simply return a bunch of 0 in stats.MemoryStats.KernelUsage.

That's not quite right:

core@localhost /sys/fs/cgroup/memory $ grep . memory.kmem.*
memory.kmem.failcnt:0
memory.kmem.max_usage_in_bytes:23629824
memory.kmem.tcp.failcnt:0
memory.kmem.tcp.limit_in_bytes:9223372036854771712
memory.kmem.tcp.max_usage_in_bytes:0
memory.kmem.tcp.usage_in_bytes:0
memory.kmem.usage_in_bytes:19554304

Kmem accounting is enabled, it's just not possible to limit it and the memory.kmem.limit_in_bytes file has been completely removed.

[lifubang]

The CI error in ci / centos-stream-9 is not releated to your commit, these flaky tests have been fixed recently. Please rebase and sign off your commit.

[jrife]

The CI error in ci / centos-stream-9 is not releated to your commit, these flaky tests have been fixed recently. Please rebase and sign off your commit.

Done

[lifubang]

LGTM, thanks, but please squash your commits.

[jrife]

LGTM, thanks, but please squash your commits.

Done

[lifubang]

@jrife Could you please open a PR to cherry-pick this commit to the branch 1.1?

[jrife]

@jrife Could you please open a PR to cherry-pick this commit to the branch 1.1?

Created #4028