Virtualized Windows 10 Idle CPU Consumption

I recently came across a rather interesting issue that seems to be relatively unrecognised – since 18xx updates, the idling Windows guest VMs seem to be consuming about 30% of CPU on the Linux KVM host. This took me a little while to get to the bottom off, and after excluding the possibility of it being caused by any active processes from inside the VM, I eventually pinned it down to the way system timers are used.


What seems to be happening is that the Windows kernel keeps polling the CPU timer all the time at a rather aggressive rate, which manifests as rather high CPU usage on the host even though the guest is not doing any productive work. On large virtualization server, this is obviously going to pointlessly burn through a huge amount of CPU for no benefit.


The solution is to expose an emulated Hyper-V clock. For all other clocks, the kernel seems to incessantly poll the timers, but for Hyper-V it recognises that this is a bad idea in a virtual machine, and starts to behave in a more sensible way.

To achieve this, add this to your libvirt XML guest definition:

      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <synic state='on'/>
      <stimer state='on'/>

This gets the VM’s idle CPU usage from 30%+ down to a much more reasonable 1%.

What is the Shortest Caching Time that Keeps Lighthouse / PageSpeed Insights happy?

Answer: 8337601 seconds. One second more than 96.5 days.

As previously mentioned, I have been working on SEO and marketing recently, and it is fascinating what insights one gains into the inner workings of things that power the digital world of today. One such example is figuring out the shortest cache time for Lighthouse / PageSpeed Insights to pass the audit.

To keep your Lighthouse / Google PageSpeed Insights happy, you should set your caching time to at least 8337601 seconds. In Apache config, that would mean adding a line like this:

Header always set Cache-Control "max-age=8337601, public"

Why would you want this to be as short as possible but long enough to keep Lighthouse happy? Well, you want to make sure that your page updates show up as quickly as possible and you don’t want stale content sticking around in the caches, reducing the effectiveness of the optimisations and improvements you make to your site all the time. At the same time, Google has said that page speed is now a ranking factor, and the algorithm they use is related to the one that Lighthouse uses.

So, if you want to set your caching time to a minimum possible time that seems to keep google happy – set it to 8337601 seconds.

Planet MySQL Controversy

Over the last few months, there has been a bit of controversy brewing around Planet MySQL’s apparent censorship of any posts that even mention a competing product, such as MariaDB, PostgreSQL or MongoDB. Given that an awful lot of tooling used in the industry supports multiple databases and not just MySQL, this is a pretty big deal and a number of prominent open source database specialists have voiced their concerns on the subject and withdrawn their posts from the Planet MySQL aggregator.

The good news is that there is now an alternative, open aggregator for open source database news at Thank you, Jean-François Gagné.