Re: Long max latencies on Wandbaord / Freescale i.MX6

[Matthias Meier <matthias.j.meier@gmx.net>]

just for imformation what causes the long latencies...

cause of the latency problem of up to 10ms was 'CONFIG_PROVE_LOCKING' 
enabled in the kernel config. After disabling it, the max latency is now 
below 400us. (many thx to tglx who found the problem).

The following arm boards have 'CONFIG_PROVE_LOCKING=y' in the defconfig 
and therefore the same problem:

ezx_defconfig
imote2_defconfig
imx_v6_v7_defconfig
moxart_defconfig
mxs_defconfig
omap2plus_defconfig

Regards
Matthias


Am 27.09.2015 um 13:49 schrieb Thomas Gleixner:
> On Sat, 26 Sep 2015, Matthias Meier wrote:
>
>> Hi,
>>
>> using cyclictest I measure long max latencies of >10ms on a Wandboard dual
>> (Freescale i.MX6 dual Cortex-A9 SoC).
>>
>> The latency problem happens with diffent scenarios:
>> - without or with rt-patch  (4.1.7-rt8 w. CONFIG_PREEMPT_RT_FULL)
>> - different Kernels (3.17, 4.1, 4.2 w. CONFIG_PREEMPT__LL)
>> - different CPU governors including 'performance'
>> - independant of CPU load
>> - even with no other userspace processes but init, the login sh and cyclictest
>> (I use a minimal builroot rfs).
>> - independant of cyclictest prio
>>
>> Using the same buildroot rfs on a A20 SoC (bananapro) with 4.1.7-rt8 shows
>> acceptable rt-latencies of ~ 200us.
>>
>> Ftracing 'irqsoff' on the rt-patched 4.1 kernel shows always long latency
>> after 'raw_spin_lock_irq' (see log below).
>>
>> Do you think it is a driver which stalls or hrtimer not working correctly on
>> this SoC or someting else?
>> If it is a driver, how could I find out which it is?
>
> Try to capture the issue with full function tracing.
>
> cyclictest --smp -p80 -m -f -b 5000
>
> That stops the tracer when the latency is > 5ms. You might have to
> increase the trace buffer size. Please upload the trace to some place
> or send it to me privately (it's over the size limit of the list).
>
> Thanks,
>
> 	tglx
>
>