Integrated: 8347129: cpuset cgroups controller is required for no good reason

Severin Gehwolf sgehwolf at openjdk.org
Tue Jan 14 19:44:39 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?

This pull request has now been integrated.

Changeset: 2de71d04
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2de71d04454b04ee887f7bd3e5decbfaa9ab8460
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8347129: cpuset cgroups controller is required for no good reason

Reviewed-by: stuefe, asmehra

-------------

PR: https://git.openjdk.org/jdk/pull/23037


More information about the hotspot-runtime-dev mailing list