Re: [RFC PATCH 2/4] sched: Use traced preempt count operations to toggle PREEMPT_ACTIVE

Frederic Weisbecker
2015-01-28T21:13:37Z

On Tue, Jan 27, 2015 at 08:42:39PM -0500, Steven Rostedt wrote:
> On Wed, 28 Jan 2015 01:24:10 +0100
> Frederic Weisbecker <fweisbec@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
>