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
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
