CPU frequency drops while running CPU and GPU tests concurrently

[Bryce_S_Intel]

Hello,

I have a customer with a Haswell-u based design which is running a Linux kernel 3.14.5 with patches provided by Intel for MSDK 2015. The Linux root file system is a CentOS 7 based rootfs.  They have also been able to replicate identical behavior described below on an Intel NUC platform.  They are using the following MSDK available from VIP

104324

Intel® Media Server Studio 2015 SDK for Linux - Beta

Media Server Studio 2015 SDK Preview 4 for 16.4

11/14/2014

5/14/2015

KIT

BIOS has Turbo disabled

The kernel governor is set to "performance".

When the board is idle, they see the frequency of the CPU cores to be 1.7GHz (max non-turbo frequency)

When they run a CPU Burn test and get the CPU utilization to be 100% the frequency on the CPU cores is 1.7 GHz

When they run a GPU test which performs 6 transcodes using the sample_multi_transcode_drm program from Intel MSDK, and run it continuously in a loop, the CPU frequency drops down to 800MHz.

Now, If I run the CPU Burn test AND the GPU test concurrently they also get the same results with the CPU frequency dropping to 800MHz, so it does not appear to be a case of the CPU being idle and going into some power save mode.

We are trying to understand why the CPU Frequency would drops down to 800MHz, it does not appear to be a temperature related event as the CPU Cores are reporting a temperature of only around 45C.

Regards

[Jeffrey_M_Intel1]

Thanks for bringing up this interesting question.  Short answer is that at least part of this behavior seems like turbo boost working as designed.  The algorithm favors the GPU, and may reduce CPU clock speed while GPU is busy even if still within thermal/power limits.  This makes balancing CPU and GPU workloads difficult, and encourages putting as much heavy work on the GPU as possible to maintain this state of boosted gpu frequency/reduced CPU frequency.

However, after doing a little research it looks like the real answer could be a lot longer. Tests on several systems (using the default 3.10 kernel install) show the CPU frequency decreasing by a lot less than what you're seeing.  There are several  kernel settings which could affect CPU frequency scaling/throttling.  BIOS settings may be configured to reduce power.  

On which processor SKUs do you see this behavior?  Is it the same with the standard CentOS 7 install using the default 3.10 kernel?  If you have access to a standard 4th-generation Core desktop/laptop, do you see similar behavior there?  

BTW, Media Server Studio 2015 R3 is available now -- for future experiments this is recommended over the previews.

[Bryce_S_Intel]

Hi Jeffrey

Customer is using a Haswell i7-4650U CPU with a base frequency of 1.7GHz. They have Turbo disabled and set the Linux governor to "performance" after the CPU boots.

As you suggested, they tried the same test with the Media Server Studio 2015 R3 and the Standard CentOS 7 kernel, 3.10.0-123.9.3 compiled with the MSDK patches.  Using this kernel they have observed 2 different behaviors:
1. The CPU frequency stays at 1.7GHz while the GPU tests execute in a loop
2. The CPU frequency starts at 1.7GHz but then drops to 800 MHz while the GPU tests executes.

The big difference in both cases appears to be the scalling driver, in the case where the CPU frequency stays high, the scaling_driver is shown as "acpi_cpufreq", in the case where the CPU frequency drops down to 800MHz, the scaling_driver is shown as "intel_pstate".

At this point we don't understand  why sometimes the intel_pstate scaling driver is used and why sometimes the acpi_cpufreq scaling driver is used.

Next step will be to compile the 3.14.5 kernel with the Media Server Studio 2015 R3 patches and verify if the results are the same.

regards,
Bryce