On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote: > On 05/27/14 12:27, Arnd Bergmann wrote: > > On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote: > >> On 05/27/14 11:49, Arnd Bergmann wrote: > >>> You also commented in that thread about stop_critical_timings()/ > >>> start_critical_timings(). Corey, can you look at that, too? I > >>> think it's designed to avoid the issue you are seeing but > >>> for some reason doesn't. > >> I sent a patch last week to "solve" this problem. I'm not sure if it's > >> right but it works for me. > >> > >> https://lkml.org/lkml/2014/5/19/607 > > I think that one was also wrong, as the intention of the existing > > stop_critical_timings() function is already to do the same that > > Corey's patch does, i.e. stop the trace before we go to idle as > > if we were turning IRQs on. > > stop_critical_timings() is called in the generic idle loop. It looks > like stop_critical_timings() just isn't written correctly. All it does > is turn off the tracer, but it doesn't prevent future calls to > spinlocks, etc. from causing the tracer to turn on again between calls > to stop/start_critical_timings(). It seems better to prevent any more > tracing from happening between a call to stop_critical_timings() and > start_critical_timings() so we don't have to litter calls to that > function throughout the idle path. But are there any such calls in the idle function? I understand what you are doing in your patch, but I don't see why you have to actually do it. Arnd -- 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
