Commits · 31e07522be566cd039ff7a770550076cc1707a0c · nexedi / linux

01 Mar, 2017 22 commits

tools/power turbostat: fix decoding for GLM, DNV, SKX turbo-ratio limits · 31e07522

Len Brown authored Jan 31, 2017

Newer processors do not hard-code the the number of cpus in each bin
to {1, 2, 3, 4, 5, 6, 7, 8}  Rather, they can specify any number
of CPUS in each of the 8 bins:

eg.

...
37 * 100.0 = 3600.0 MHz max turbo 4 active cores
38 * 100.0 = 3700.0 MHz max turbo 3 active cores
39 * 100.0 = 3800.0 MHz max turbo 2 active cores
39 * 100.0 = 3900.0 MHz max turbo 1 active cores

could now look something like this:

...
37 * 100.0 = 3600.0 MHz max turbo 16 active cores
38 * 100.0 = 3700.0 MHz max turbo 8 active cores
39 * 100.0 = 3800.0 MHz max turbo 4 active cores
39 * 100.0 = 3900.0 MHz max turbo 2 active cores
Signed-off-by: Len Brown <len.brown@intel.com>

31e07522

tools/power turbostat: skip unused counters on SKX · 34c76197

Len Brown authored Jan 27, 2017

Skip these four counters on SKX, as they are always zero:
cc3, pc3
cc7, pc7
Signed-off-by: Len Brown <len.brown@intel.com>

34c76197

tools/power turbostat: Denverton: use HW CC1 counter, skip C3, C7 · 7170a374

Len Brown authored Jan 27, 2017

The CC1 column in tubostat can be computed by subtracting
the core c-state residency countes from the total Cx residency.

CC1 = (Idle_time_as_measured by MPERF) - (all core C-states with
residency counters)

However, as the underlying counter reads are not atomic,
error can be noticed in this calculations, especially
when the numbers are small.

Denverton has a hardware CC1 residency counter
to improve the accuracy of the cc1 statistic -- use it.

At the same time, Denverton has no concept of CC3, PC3, CC7, PC7,
so skip collecting and printing those columns.

Finally, a note of clarification.
Turbostat prints the standard PC2 residency counter,
but on Denverton hardware, that actually means PC1E.
Turbostat prints the standard PC6 residency counter,
but on Denverton hardware, that actually means PC2.

At this point, we document that differnce in this commit message,
rather than adding a quirk to the software.
Signed-off-by: Len Brown <len.brown@intel.com>

7170a374

tools/power turbostat: initial Gemini Lake SOC support · ac01ac13

Len Brown authored Jan 27, 2017

Gemini Lake is similar to Apollo Lake (Broxton/Goldmont)
Signed-off-by: Len Brown <len.brown@intel.com>

ac01ac13

x86: intel-family.h: Add GEMINI_LAKE SOC · 311f7770
Len Brown authored Feb 16, 2017
```
Cc: x86@kernel.org
Signed-off-by: Len Brown <len.brown@intel.com>
```
311f7770

tools/power turbostat: bug fixes to --add, --show/--hide features · 0f47c08d

Len Brown authored Jan 27, 2017

Fix a bug with --add, where the title of the column
is un-initialized if not specified by the user.

The initial implementation of --show and --hide
neglected to handle the pc8/pc9/pc10 counters.

Fix a bug where "--show Core" only worked with --debug
Reported-by: Wendy Wang <wendy.wang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>

0f47c08d

tools/power turbostat: use tsc_tweak everwhere it is needed · 008d396e

Len Brown authored Feb 10, 2017

The CPU ticks at a rate in the "bus clock" domain.
eg. 100 MHz * bus_ratio.

On newer processors, the TSC has been moved out of this BCLK
domain and into a separate crystal-clock domain.

While the TSC ticks "close to" the base frequency, those that look
closely at the numbers will notice small errors in calculations that
mix units of TSC clocks and bus clocks.

"tsc_tweak" was introduced to address the most visible
mixing -- the %Busy and the the Busy_MHz calculations.
(A simplification as since removed TSC from the BusyMHz calculation)

Here we apply the tsc_tweak to everyplace where BCLK
and TSC units are mixed.  The results is that
on a system which is 100% idle, the sum of the C-states
are now much more likely to be closer to 100%.
Reported-by: Travis Downs <travis.downs@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>