On Fri, 26 Oct 2012, Thomas Gleixner wrote: > On Fri, 26 Oct 2012, Stanislav Meduna wrote: > > The command > > echo 1000000 > /proc/sys/kernel/sched_rt_runtime_us > > fixes the problem but is not really something I want > > to enable when developing a real-time capable system > > that will be running in remote locations. With 980000 > > I still get negligible latencies. With 970000 I get 4 ms. > > With 960000 I get 15 ms latencies. So it is indeed > > the throttling that is firing here. > > Right. So that means that the pata irq or something else loops in > circles for whatever reasons. > > For a simple test, can you just set the pata irq thread to SCHED_OTHER > with chrt? Does that cure the problem? > > Aside of that I'd really like to see a full function trace of that > scenario. Can you please apply the patch below and run that with the > function tracer enabled. The throttling will stop the trace right at > the point. Ok. The trace shows what happens. The pata driver runs all of its work in the interrupt handler context and the hardware is fast enough to saturate the machine. I.e. right after the handler returns and reenables interrupts the next pata irq fires. Lather rinse and repeat. On mainline you'd just see the machine stalling for a bit as it would process interrupts and nothing else. Of course you wont see rt throttling because all of this happens in hard interrupt context, except if you force interrupt threading via "threadirqs" on the kernel command line. There is not much we can do about that unless we want to do a major surgery on that pata driver code. So either you disable the throttler or you reconfigure the pata irq thread to SCHED_OTHER, which will slow it down a bit, but avoids the hogging of the machine with a RT task going wild. 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
