Performance analysis of Chrome on Ryzen CPU platforms has showed that the CPU core boost feature is somewhat stunted when Chrome is run and therefore the performance reached for web workloads is not quite as it could be, when Hyper-V is active on the platform (which is used in some client scenarios by Microsoft e.g. for DeviceGuard & CredentialGuard feature, which are part of the “virtualization based security” feature Microsoft is promoting for the commercial/enterprise Windows use).

This results in about a 10% perf loss in CPU focused workloads in e.g. Octane v2 and other packaged benchmarks and similar numbers for similar user experience scenarios.

This is because Chrome is using the Windows Multimedia timers being set to a 1ms resolution. The reason for the core boost being limited is in the Windows OS C-state management when the system uses PHYSICAL_DESTINATION mode for the IOMMU (which is activated in AMDs case).

Increasing the MMTimer setting to 4, 5 or 10 ms resolution improves the behavior here when Virtualization Based Security mode is active. The involvement of the Hypervisor virtualization substantially increases the cost of interrupt processing and other such system operations.

An application can identify if Virtualization Based Security mode is active by using NtQuerySystemInformation() with the SYSTEM_CODEINTEGRITY_INFORMATION query key.

Alternately this can be summarized as "Having a high interrupt frequency is bad because it wastes CPU time by forcing cores to wake up many more times per second. This also prevents them from getting into a deep sleep state. These costs are exacerbated when Virtualization Based Security is used."


Aside (supporting evidence for 10 ms interval being fine):

Should be also noted that on modern Windows platforms (since Windows 8.1, actually) the OS Desktop Window Manager is pretty good in handling so-called timed presents for video playback. Which means that the OS Desktop Window Manager directly deals with the application render target display surface for display scanout instead of forcing a composition step in most cases (using the so-called DirectFlip feature in the drivers). That reduces the overhead and allows the application to delegate the Present timing responsibility to DWM robustly. It also allows the driver and appropriate displays that support variable refresh rate which is a standardized DisplayPort and supported by a lot of internal panels too, e.g. just search for the “AMD FreeSync supported” which is what this VESA feature is branded at on the AMD side. To note, Nvidia does a proprietary feature called GSync which is not standardized, though typically will work with the same OS API control interfaces below if you happen to get the right monitor and graphics card pairing (AMD’s is more flexible and vendor-neutral due to VESA standardization).

The system benefit Is that the frame timing on the display can be set exactly to the video stream frame rate (e.g. 48Hz for 24fps movie content or similar), shaving off a number of updates and interpolations and therefore reducing the power consumption on video playback substantially while keeping perfect timing to the video stream. So that would also allow to reduce the MMTimer rate substantially.

To allow the driver to take advantage of this feature on Windows 8.1 and above, the application  can use the IDXGISwapChainMedia interface https://msdn.microsoft.com/en-us/library/windows/desktop/dn384131(v=vs.85).aspx by using the SetPresentDuration method.

It’s a pretty cool Windows feature actually, which some browsers already take advantage of.