Re: [PATCH 19/21] tracing: Account for preempt off in preempt_schedule()

Steven Rostedt
2011-09-23T11:19:14Z

On Fri, 2011-09-23 at 13:00 +0200, Peter Zijlstra wrote:
>
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > ---
> > kernel/sched.c | 9 +++++++++
> > 1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index ccacdbd..4b096cc 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -4435,7 +4435,16 @@ asmlinkage void __sched notrace preempt_schedule(void)
> >
> > do {
> > add_preempt_count_notrace(PREEMPT_ACTIVE);
> > + /*
> > + * The add/subtract must not be traced by the function
> > + * tracer. But we still want to account for the
> > + * preempt off latency tracer. Since the _notrace versions
> > + * of add/subtract skip the accounting for latency tracer
> > + * we must force it manually.
> > + */
> > + start_critical_timings();
> > schedule();
> > + stop_critical_timings();
> > sub_preempt_count_notrace(PREEMPT_ACTIVE);
> >
> > /*
>
> This won't apply, you're patching ancient code.

Yes, that's the way git usually works. I could start a new branch for
this. But since we are not doing many pulls while kernel.org is down, my
kernel base has become a bit out of date. I thought that's the way Linus
wants it. I'm sure this would apply with a trivial merge fixup.

But if you want to take this patch, then I could rebase my tree and take
it out.

>
> Anyway, this all stinks, and reading the changelog of
> d1f74e20b5b064a130cd0743a256c2d3cfe84010 and the above just makes me
> confused.
>

What would you suggest? Just ignore the latencies that schedule
produces, even though its been one of the top causes of latencies?

-- Steve