Description of problem:

The node labeller marks the nodes with:

• their exact TSC frequency
• the lowest TSC frequency in the cluster IF they support tsc-scalable

Hypothetical example, on a cluster where the lowest frequency is X

NAME TSC-FREQUENCY TSC-SCALABLE TSC-FREQUENCY-X TSC-FREQUENCY-Y
node1 X true true
node2 Y true true true
node3 Y false true

However, TSC scaling may not be an exact number in many CPU models, leaving some possible variation.

See this, same CPU on 2 different systems (or even same system and 2 reboots), there is a 1 Mhz difference that can show up between reboots or systems with same CPU

[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2297.345 MHz processor
[ 4.127014] tsc: Refined TSC clocksource calibration: 2297.339 MHz

[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2297.449 MHz processor
[ 4.063010] tsc: Refined TSC clocksource calibration: 2297.338 MHz

If we do X = 2297.338
Y = 2297.339
Then a Windows VM with re-enlightenment will never run on node3, because its missing TSC-FREQUENCY-X label by 1MHZ off.
The logic will consider this an heterogeneous cluster, but its not.

The system should be able to schedule VMs on any of those 3 nodes, regardless of TSC-SCALABLE or not. Because these are essentially the same frequency.
Lower layers accept this variance, BZ1839095

Version-Release number of selected component (if applicable):
4.12.10

How reproducible:
Always

Steps to Reproduce:
1. Use systems with TSC-SCALABLE = false and same CPUs, reboot until different frequencies.

Actual results:

• VMs fail to schedule on nodes with same CPU

Expected results:

• VMs scheduled