The guy behind the Linux kernel, Linus Torvalds, has built version 4.10 of the mainline kernel—nicknamed “Fearless Coyote.” Like any new kernel, version 4.10 has a slew of improvements for compatibility with a wide range of hardware. As I was digging through the commit log to see what’s new (a lot, actually), an entry on Kaby Lake caught my eye.

Turns out, if you’ve been running a desktop Intel Kaby Lake CPU with Linux, there’s a chance you haven’t been getting your money’s worth. Kernel (4.10) patches a little bug that may yield extra performance in some desktop systems.

What’s a mainline kernel?

First, I should explain why kernel 4.10 is known as a “mainline” kernel (at time of writing). The mainline kernel is the fresh-from-Linus-himself build of the Linux kernel, and contains all the new features and improvements to the kernel. Along with those new features comes the potential for breakage. Major versions of mainline kernels (like 4.10) become “stable” before they are officially released for public consumption. Stable kernels are generally good to use as-is, but many users will want to stick to the distribution-specific kernel that’s available through their package managers.

More: How to update your kernel

At the time of writing, kernel.org lists version 4.9.12 as the current stable kernel.

Motherboard miscommunication

When you buy new PC parts or a prebuilt system, it’s natural to assume that compatible parts will perform together optimally. But that’s not always the case. Linux users who built (or bought) a desktop system with the latest Kaby Lake processor, might’ve been deprived of full performance, thanks to a glitch with some motherboards. Fortunately, a patch by Intel’s Srinivas Pandruvada found in kernel 4.10 fixes the problem. Unfortunately, there’s no published list of affected motherboards.

The patch addresses a kernel driver called intel_pstate, which helps the kernel tell the CPU how much power to use. By default, intel_pstate has two settings: powersave and performance. Powersave mode, of course, reduces power and optimizes efficiency, while performance mode says, “To hell with efficiency, we want MORE POWER!” (Cue Tim Allen noises.)

Some processors and motherboards will attempt to do this automatically at the BIOS level, so the kernel doesn’t have to get involved. In this mode, known as hardware P-state, or HWP, the BIOS reports the power state back to the kernel to let it know it’s handling the power state settings.

If this sounds a bit complex, think of it as the motherboard telling Linux kernel, “Hey, don’t worry about the power state of the CPU, I got this.” Before the patch, the kernel would take this statement as canon, and go about its business, assuming that the power state was being handled appropriately. Unfortunately, some motherboards were telling the kernel a few alternative facts about the CPU’s power state.

When running below the maximum load, everything was fine, but at maximum load some BIOSes wouldn’t send the CPU into turbo mode, Pandruvada noted in his commit message; instead they were using a power-saving setting that wasn’t recommended for the CPU.

“Some Kaby Lake desktop processors may not reach max turbo when running in HWP mode, even if running under sustained 100% utilization,” Pandruvada wrote. “This occurs when the HWP.EPP (Energy Performance Preference) is set to ‘balance_power’ (0x80)—the default on most systems.”

This has real-world implications. If you were using an Intel Core i7-7700, which has a base frequency of 3.6GHz, you might never hit the CPU’s turbo of 4.20GHz. This equates to 600MHz (or 14.3 percent) of unrealized performance. Considering the i7-7700 is a $350 CPU, that’s not cool—performance is coming up short where you need it most, in high-demand tasks like gaming and video editing.

Under the radar

Windows users running the CPU and motherboard combinations didn’t notice this flaw in CPU P-state reporting because of the way Windows handles reports from the BIOS. According to Pandruvada, the Windows kernel requires that the BIOS return a table of the system’s power information when running in HWP mode. If that information is missing, as it was with the erroneous reports from the affected BIOSes, Windows drops back to a legacy P-state mode that ignores HWP and does things the old-fashioned way.

The Linux kernel doesn’t require this table and therefore doesn’t check for it. Thus, Linux systems would happily assume the BIOS was working up to snuff.

Getting around the problem

Before the patch was applied to the kernel, there were a couple ways to get around this behavior.

First, Linux could operate in the legacy P-state mode (the kind that Windows falls back to) in order to bypass the HWP settings. To do this, the user would have to edit their bootloader to load the kernel with a specific setting (intel_pstste=disable). For a Linux newbie, that can be a tall order, since altering the grub.cfg bootloader incorrectly can result in a system that won’t boot. While this is fairly easy to fix, it can be scary for novices, and can even be annoying for seasoned users.

Another option was to set the power state to “performance” in the BIOS. For most motherboards in home-built systems, the BIOS offers a plethora of tuning options, so this isn’t tough to do. (Users who like to overclock their systems usually ensure that “performance” is enabled anyway.) However, if you’re using a desktop system without a full-featured BIOS, that setting may be hard to find, if it’s there at all.

Linux 4.10 won’t require users to do either of these things, and “powersave” should work as originally intended, turbo and all. While this is great news for desktop Kaby Lake owners, it’s far from the only improvement in Linux 4.10. This kernel will be making its way to distributions soon, so keep your kernel updated.