[LAD] cpu spikes

Joakim Hernberg jhernberg at alchemy.lu
Mon Jan 25 11:29:06 UTC 2016

On Sun, 24 Jan 2016 15:03:08 +0100
Fokke de Jong <fokkedejong at gmail.com> wrote:

> I am measuring cpu load by getting the time with
> clock_gettime(CLOCK_MONOTONIC_RAW, timespec*) at the beginning and
> end of each callback. When converted to a percentage my cpu load
> hovers somewhere between 40 an 50% most of the time, but more or less
> every 900 callbacks (0.8 seconds there is a spike of more than 100%.
> I remember reading somewhere that realtime threads cannot run more
> than .95s every second. That would be very bad if it actually meant
> my threads are blocked  run for a period of 50ms straight…

You can disable the realtime runtime throttling if that is a problem,
but I'd doubt that would be the reason for your troubles, and it's
unlikely to cause problems unless you're really maxing out the CPUs.

Other reasons could range from hardware/kernel modules that aren't
playing nice with RT to wifi drivers and the NVIDIA module also comes to
mind.  Your system could also be suffering from SMI/NMI that runs out
of BIOS and completely preempts the kernel.

There are testing utilities in a package called rt-tests.  Try to run
cyclictest like this (sudo) "cyclictest -S -m -p98".  cyclictest
schedules threads to be run at a certain time, and can be used to get a
pretty good idea of kernel scheduling latencies.  It's the max that is
interesting to us, and hopefully yours will be under 100us, but if you
have peaks that go much higher that could be a reason for audio

Best to run it in the background for a while, and even better would be
to put load on the system.  The hackbench utility can be used for that.

Another reason could be cpu power management, though on a modern intel
processor that appears to be a thing of the past.

I suppose hyperthreading could be a potential pitfall, but personally I
see no problems with it with my audio workloads on my i7.



More information about the Linux-audio-dev mailing list