RFR: 8347129: cpuset cgroups controller is required for no good reason
Ashutosh Mehra
asmehra at openjdk.org
Tue Jan 14 17:55:41 UTC 2025
On Fri, 10 Jan 2025 14:14:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:
> Please review this small change to make the `cpuset` cgroups controller optional as far as the JDK is concerned. The rationale is that:
>
> - Some distributions now don't have it enabled by default (e.g. Fedora 41), which breaks automatic container detection logic.
> - CPU limits enforced with `--cpuset-cpus` is reflected with the `sched_getaffinity` system call and, thus, the controller doesn't need to be mandatory. The current failure to detect the controller results in no container limits being detected with is bad.
>
> The fix is rather simple. Make `cpuset` controller look-up from `/proc/cgroups` optional (like the `pids` controller) and continue. `OSContainer::active_processor_count()` still behaves as before (should there be a `cpuset` limit) as it's covered by `os::Linux::active_processor_count()` which serves as the upper bound of other container cpu limits.
>
> While at it, I've also fixed the logging bug by re-arranging the `const char*` values. `cpuset` is index `0`, `cpu` is index `1`.
>
> Testing:
> - [x] GHA
> - [x] Linux container tests in `test/hotspot/jtreg/containers` on Linux cgroups v1 and cgroups v2 as well as on an affected system (F41 on cg v2). All pass.
>
> Thoughts?
looks good.
-------------
Marked as reviewed by asmehra (Committer).
PR Review: https://git.openjdk.org/jdk/pull/23037#pullrequestreview-2550596374
More information about the hotspot-runtime-dev
mailing list