Messages in this thread | | | Date | Wed, 27 Jan 2021 11:15:47 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH] sched/tracing: Reset critical timings on scheduling |
| |
On Wed, 27 Jan 2021 12:37:16 +0100 Peter Zijlstra <peterz@infradead.org> 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
| |