PROVE_LOCKING is not so bad I thought
finally I guess my latency problem is caused by a spurious interrupt on
a unused mmc slot causing heavy load when using PROVE_LOCKING ...
Here a little more in detail what I did:
Disabling CONFIG_PROVE_LOCKING together with a lot other debug options
as Thomas proposed indeed gave max latencies in the range of 100us - at
least most of the time...
After adding besides 'hackbench' additional heavy network load via the
on-board WiFi interface, the max latency raised further and finally I
the kernel fired a backtrace which ended in a "Disabling IRQ #284"
/proc/interrupts indeed shows a hugh amout of interrupts on mmc1
although I don't use mmc1 at all (the Wandboard boots via mmc0)
(possible a pullup config is missing at the mmc interfaces?)
After reboot I tried to stop the spurious interrupts by inserting a
sd-card on mmc1 but this does not work - still high interrupts.
Now I'm trying to disable mmc1 and mmc2 completely which is not as easy
as I thought: via sysfs it seems not to be possible and via DT I think I
would have to modify all imx6* DTS files of all imx6 boards - otherwise
the dtbs does not compile...
Is there a simple solution to disable either a single interrupt or a
individual mmc interface from userspace?
Thanks,
Matthias
--
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
