Re: [PATCH] sched/tracing: Reset critical timings on scheduling

From: Steven Rostedt
Date: Wed Jan 27 2021 - 11:20:07 EST


On Wed, 27 Jan 2021 12:37:16 +0100
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> And that's just really daft.. why are you adding two unconditional
> function calls to __schedule() that are a complete waste of time
> 99.999999% of the time?
>
> If anything, this should be fixed in schedule_idle().

Note, those two unconditional calls are only called when you have the
preempt or irqs off latency tracers enabled (which causes overhead on every
preempt_enable/disable and irqs enabled/disabled as well, and why we tell
people not to compile them in if you care about performance).

When irqs and preempt latency tracers are not enabled, we have this:

# define stop_critical_timings() do { } while (0)
# define start_critical_timings() do { } while (0)

static inline void reset_critical_timings(void) {
stop_critical_timings();
start_critical_timings();
}

which is basically a nop.

If you still care about the overhead to schedule when these tracers are
enabled (which is not much considered the overhead they cause elsewhere), we
can make it more specific to cpu idle.

I was worried that this could happen more than just in cpu idle, and added
it to the scheduler directly to make sure I got any other case.

-- Steve