MEDIUM: cpu-topo: prefer grouping by CCX for "performance" and "efficiency"

Most of the time, machines made of multiple CPU types use the same L3
for them, and grouping CPUs by frequencies to form groups doesn't bring
any value and on the opposite can impair the incoming connection balancing.
This choice of grouping by cluster was made in order to constitute a good
choice on homogenous machines as well, so better rely on the per-CCX
grouping than the per-cluster one in this case. This will create less
clusters on machines where it counts without affecting other ones.

It doesn't seem necessary to change anything for the "resource" policy
since it selects a single cluster.

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 34b3f1667bad300483ee4b620a58eacb948a1d86..ecdd87a453f232c70091763b2b4afaf60fbe5727 100644 (file)
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -1992,7 +1992,7 @@ cpu-policy <policy>
                         systems, per thread-group. The number of thread-groups,
                         if not set, will be set to 1.
 
-   - efficiency         exactly like group-by-cluster below, except that CPU
+   - efficiency         exactly like "group-by-ccx" below, except that CPU
                         clusters composed of cores whose performance is more
                         than 25% above that of the next less performant one are
                         evicted. These are typically "big" or "performance"
@@ -2098,7 +2098,7 @@ cpu-policy <policy>
                         laptops and desktop machines used by developers and
                         admins to validate setups.
 
-   - performance        exactly like group-by-cluster above, except that CPU
+   - performance        exactly like "group-by-ccx" above, except that CPU
                         clusters composed of cores whose performance is less
                         than 80% of those of the next more performant one are
                         evicted. These are typically "little" or "efficient"
@@ -2110,7 +2110,7 @@ cpu-policy <policy>
                         auxiliary tools such as load generators and monitoring
                         tools.
 
-   - resource           this is like group-by-cluster above, except that only
+   - resource           this is like "group-by-cluster" above, except that only
                         the smallest and most efficient CPU cluster will be
                         used, while all other ones will be ignored. This can be
                         used to limit the resource usage to the strict minimum

diff --git a/src/cpu_topo.c b/src/cpu_topo.c
index a8019d06146ec6e8e912eb3dbe1e3acbc5d4980f..45cff86ee1301a64089adff15f5130835196d8d2 100644 (file)
--- a/src/cpu_topo.c
+++ b/src/cpu_topo.c
@@ -1353,8 +1353,10 @@ static int cpu_policy_performance(int policy, int tmin, int tmax, int gmin, int
 
        cpu_cluster_reorder_by_index(ha_cpu_clusters, cpu_topo_maxcpus);
 
-       /* and finish using the group-by-cluster strategy */
-       return cpu_policy_group_by_cluster(policy, tmin, tmax, gmin, gmax, err);
+       /* and finish using the group-by-ccx strategy, which will split around
+        * L3 rather than just cluster types.
+        */
+       return cpu_policy_group_by_ccx(policy, tmin, tmax, gmin, gmax, err);
 }
 
 /* the "efficiency" cpu-policy:
@@ -1395,8 +1397,10 @@ static int cpu_policy_efficiency(int policy, int tmin, int tmax, int gmin, int g
 
        cpu_cluster_reorder_by_index(ha_cpu_clusters, cpu_topo_maxcpus);
 
-       /* and finish using the group-by-cluster strategy */
-       return cpu_policy_group_by_cluster(policy, tmin, tmax, gmin, gmax, err);
+       /* and finish using the group-by-ccx strategy, which will split around
+        * L3 rather than just cluster types.
+        */
+       return cpu_policy_group_by_ccx(policy, tmin, tmax, gmin, gmax, err);
 }