Krun incorrectly checks if turbo mode is enabled.

I've realised that Krun is not correctly checking if turbo mode is disabled.

The code looks like this:

Line 1143 in 187a4e6

# Check "turbo boost" is disabled

class LinuxPlatform(UnixLikePlatform):
    ...
    TURBO_DISABLED = "/sys/devices/system/cpu/intel_pstate/no_turbo"
    ...
        # Check "turbo boost" is disabled
        # It really should be, as turbo boost is only available using pstates,
        # and the code above is ensuring we are not. Let's check anyway.
        debug("Checking 'turbo boost' is disabled")
        if os.path.exists(LinuxPlatform.TURBO_DISABLED):
            with open(LinuxPlatform.TURBO_DISABLED) as fh:
                v = int(fh.read().strip())

            if v != 1:
                fatal("Machine has 'turbo boost' enabled. "
                      "This should not happen, as this feature only applies to "
                      "pstate CPU scaling and Krun just determined that "
"the system is not!")

Here's the issue. The sysfs file only exists if you are using the pstate cpufreq driver. Krun insists that we don't use that driver! So this check is ineffectual. The comment in the code is inaccurate, so don't be fooled. Turbo mode can be active even with the pstate driver disabled.

In production mode, you would quickly see that turbo mode is enabled, thanks to the a/mperf ratio checks, but if you run on a stock kernel, you would be oblivious.

First, I propose the above code should assert that the file doesn't exist, as it's existence implies the wrong cpufreq driver is in use.

Second, we need a way to check if turbo mode is enabled in the absence of the sysfs file. Turbo mode can be queried (on some CPUs) by looking at bit 38 of the IA32_MISC_ENABLE MSR, so it should be possible to check...

I've just found msr-tools (https://01.org/msr-tools), which we could shell out to, instead of writing more kernel code, but we might also have to write some assembler code to figure out if the CPU supports turbo mode at all. Most CPUs we will run on will support turbo mode, but I think it will be a good sanity check to implement too.

Any comments?

We definitely don't want to write more kernel code for this. We could even run a loop and check APERF/MPERF before/after? It's a hack though...

Yeah, that's a hack. I'd rather query the hardware for a definitive answer.

I've just found that we can ask if the CPU does turbo mode with CPUID 0x06, and I can do that in userspace, so I think I have a plan.