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