[jdk16] RFR: 8259765: ZGC: Handle incorrect processor id reported by the operating system [v2]

[Florian Weimer]

* Per Liden:

> There seems to be a disconnect between CPU masks/affinity and what sched_getcpu() returns.
>
> Example (container with 1 CPU):
>
> 1. sysconf(_SC_NPROCESSORS_CONF) returns 1
> 2. sysconf(_SC_NPROCESSORS_ONLN) returns 1
> 3. sched_getaffinity() returns the mask 00000001
> 4. sched_setaffinity(00000001) return success, but then sched_getcpu() returns 7(!) Should have returned 0.
>
> Another example (container with 2 CPUs):
>
> 1. sysconf(_SC_NPROCESSORS_CONF) returns 2
> 2. sysconf(_SC_NPROCESSORS_ONLN) returns 2
> 3. sched_getaffinity() returns the mask 00000011
> 4. sched_setaffinity(00000001) returns success, but then sched_getcpu() returns 2(!). Should have returned 0.
> 5. sched_setaffinity(00000010) returns success, but then sched_getcpu() also returns 2(!). Should have returned 1.

Does sched_getaffinity actually change the affinity mask?

I wonder if it just reports a 2**N - 1 unconditionally, with N being the
number of configured vCPUs for the container.  It probably does that so
that the population count of the affinity mask matches the vCPU count.
Likewise for the CPU entries under /sys (currently ignored by glibc
because of a parser bug) and /proc/stat (the fallback actually used by
glibc).  There is no virtualization of CPU IDs whatsoever, it looks like
it's all done to communicate the vCPU count, without taking into account
how badly this interacts with sched_getcpu.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill