Re: [LAD] Kontakt Spikes

From: Michael Ost <most@email-addr-hidden>
Date: Tue Oct 11 2011 - 03:41:32 EEST

On 10/10/2011 03:04 PM, Clemens Ladisch wrote:
> Michael Ost wrote:
>> Have you ever seen "migration" or "watchdog" hold the CPU for any length of time?
>
> This shouldn't happen.
>
>> I was curious about "migration" since
>>
>> /proc/sys/kernel/sched_migration_cost = 500000
>
> When migrating threads to another CPU (core), there is no big delay
> because real-time threads have well-defined scheduling behaviour and
> either interrupt the running thread immediately or go into the runnable
> queue like other threads that already are on that CPU.
>
> The reason that the cost is set so high is that the new thread will run
> slower because it has to pull over its data from the other cache.
>
>
> I guess I can rule out SMIs because those should happen even when there
> is one thread per core.

Are these "System Management Interrupts"? I'm not familiar with them. A
google search shows that 'hwlatdetect.py' can be used to detect them. I
will run that during the spikes to see if anything turns up.

> How big are the latencies you're seeing? They are not from being
> interrupted by another RR thread at the same priority (see "man
> sched_rr_get_interval")?

We are wiring up the ftrace system in the kernel and cyclictest to find
out for certain. It's looking like it could be 10s of milliseconds, when
there is only 2.9 msecs to process (44.1k/128 samples). I should be able
to get more information tomorrow.

Thanks again,

Michael Ost
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Oct 11 04:15:01 2011

This archive was generated by hypermail 2.1.8 : Tue Oct 11 2011 - 04:15:01 EEST