On Tue, Jan 27, 2015 at 08:42:39PM -0500, Steven Rostedt wrote:
> On Wed, 28 Jan 2015 01:24:10 +0100
> Frederic Weisbecker <fweis...@gmail.com> wrote:
>
> > d1f74e20b5b064a130cd0743a256c2d3cfe84010 turned PREEMPT_ACTIVE modifiers
> > to use raw untraced preempt count operations. Meanwhile this prevents
> > from debugging and tracing preemption disabled if we pull that
> > responsibility to schedule() callers (see following patches).
> >
> > Is there anything we can do about that?
> >
>
> I'm trying to understand how you solved the recursion issue with
> preempt_schedule()?
I don't solve it, I rather outline the issue to make sure it's still
a problem today. I can keep the non-traced API but we'll loose debuggability
and latency measurement in preempt_schedule(). But I think this was already
the case before my patchset.
>
> Here's what happens:
>
> preempt_schedule()
> preempt_count_add() -> gets traced by function tracer
> function_trace_call()
> preempt_disable_notrace()
> [...]
> preempt_enable_notrace() -> sees NEED_RESCHED set
> preempt_schedule()
> preempt_count_add() -> gets traced
> function_trace_call()
> preempt_disable_notrace()
> preempt_enable_notrace() -> sees NEED_RESCHED set
>
> [etc etc until BOOM!]
>
> Perhaps if you can find a way to clear NEED_RECHED before disabling
> preemption, then it would work. But I don't see that in the patch
> series.
Something like this in function tracing?
prev_resched = need_resched();
do_function_tracing()
preempt_disable()
.....
preempt_enable_no_resched()
if (!prev_resched && need_resched())
preempt_schedule()
Sounds like a good idea. More overhead but maybe more stability.
>
> -- Steve
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
