There are many modern systems where a single package can contain multiple NUMA nodes. We want to test the differences across those NUMA nodes as well.
The relationship between NUMA and packages are complicated. There are cases when there are multiple NUMA nodes per package, and when there are multiple packages per NUMA node (for example, "simulated" flat memory layout). This makes the NUMA placement in the "resource" hierarchy rather complicated.
I believe as the stop-gap we can just treat NUMA node as "package", if NUMA is enabled and there is a single package. In the case of multiple packages per NUMA node, it would imply several packages, and we would fall-back to per-package scheduling.
The relationship between NUMA and packages are complicated. There are cases when there are multiple NUMA nodes per package, and when there are multiple packages per NUMA node (for example, "simulated" flat memory layout). This makes the NUMA placement in the "resource" hierarchy rather complicated.
I believe as the stop-gap we can just treat NUMA node as "package", if NUMA is enabled and there is a single package. In the case of multiple packages per NUMA node, it would imply several packages, and we would fall-back to per-package scheduling.
- links to
-
Review openjdk/jcstress/128