topic Background processes for most cpu frequency stability? in Software Tuning, Performance Optimization & Platform Monitoring

Background processes for most cpu frequency stability?

Thomas_H_1 — Tue, 10 Oct 2017 23:34:45 GMT

Hi all,

I'm trying to get the Jack audio server to run smoothly on Linux and this seems to be less glitchy the more I restrict the cpu frequency.

Disabling SpeedStep doesn't seem to prevent cpu frequency scaling (even though the BIOS says “Disabled = Places the processor into the highest performance state and prevents the Intel Speedstep applet or native operating system driver from adjusting the processor's performance.” which suggests that it is meant to...), but it does reduce the number of glitches.

With the scaling governor set to ‘performance’, i7z reports that the cores have a frequency range of around 2584.53 to 2595.74, but if I use the program ‘hackbench’ to generate background processes to max out the processor, stability increases and the frequency range becomes 2592.95 to 2592.96. Is there a way to get that stability without hackbench's background processes?

I'm using a Intel Core i5-6440HQ Processor (Quad Core 2.60GHz, 3.50GHz Turbo, 6MB 45W, w/Intel HD
Graphics 530) with a recent BIOS update.

Thanks for any advice that can be provided :)

Tom

In general, the Power Control

McCalpinJohn — Mon, 16 Oct 2017 15:35:21 GMT

In general, the Power Control Unit on Intel processors feels free to lower the frequency of idle processors. As far as I can tell, this cannot be overridden by BIOS or OS options. It has minimal impact on the performance of long-running processes, but the frequency changes incur a latency penalty that could be significant for a process that runs for a very short period of time (with sleeping between periods of activity).

One recommendation that I have seen is to put a "spinner" process in the background at the lowest possible priority. Something like:

taskset -c <target_core> nice 19 ./spinner

This will ensure that the <target_core> is never idle, but the "spinner" program should never steal cycles from any other application.

Your processor does not support HyperThreading, which makes things a bit easier. The approach above will slow down the application if the spinner and the application are pinned to different logical processors on the same physical processor (since the OS sees those as different processors, it will schedule them at the same time, and they will share the hardware resources).