https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127651
Bug ID: 127651
Summary: On Linux, libgomp detects the wrong number of
available CPUs when cgroups are used (i.e. Docker,
Kubernetes, systemd-run, etc)
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: itamar at pythonspeed dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
By default libgomp will use a number of threads equal to the number of cores.
But there are a variety of ways cgroups (as used by Docker, Kubernetes, etc)
can restrict CPU availability, and libgomp does not know about all of them.
Without knowing about these restrictions, the result can be code running in a
container (e.g. Kubernetes pod) thinking it has far more cores than it actually
does, since it will choose the physical CPU count instead of the restricted
access the container has been given. This can cause oversaturation and
slowness.
Inspecting the code suggests this is still true in latest gcc/libgomp.
Reproducer:
```
#include <omp.h>
#include <stdio.h>
int main() {
printf("%d\n", omp_get_max_threads());
return 0;
}
```
And then we can see that CPU affinity is respected (taskset) but cgroups
settings are not (Docker, systemd-run):
```
$ gcc -fopenmp how_many_threads.c
$ ./how_many_threads
12
$ taskset -c 0-2 ./how_many_threads
3
$ systemd-run --user --scope --property CPUQuota="200%" -- ./how_many_threads
Running as unit: run-p1792790-i5994604.scope; invocation ID:
2d06fb6b4fd24bc887886fbd98af008b
12
$ docker run --cpus 3 -v $PWD:/mounted almalinux:10 /mounted/how_many_threads
12
```
