[Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

[Chris Wilson]

Quoting Steven Rostedt (2018-03-30 14:48:45)
> On Thu, 29 Mar 2018 23:25:57 +0100
> Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
> > Across suspend, we may see a very large drift in timestamps if the sched
> > clock is unstable, prompting the global trace's ringbuffer code to warn
> > and suggest switching to the global clock. Preempt this request by
> > detecting when the sched clock is unstable (determined during
> > late_initcall) and automatically switching the default clock over to
> > trace_global_clock.
> > 
> > This should prevent requiring user interaction to resolve warnings such
> > as:
> > 
> >     Delta way too big! 18446743856563626466 ts=18446744054496180323 write stamp = 197932553857
> >     If you just came from a suspend/resume,
> >     please switch to the trace global clock:
> >     echo global > /sys/kernel/debug/tracing/trace_clock
> 
> global clock has a much higher overhead than the local clock. I rather
> not have it automatically switch even when there's no stable TSC. That
> will be annoying to myself as I have boxes that this would switch on
> and I prefer to keep the local clock.

My counter argument would be that it comes as a bit of a shock to the
user to find out their debugging session was rendered invalid because
the tracer chose to use a clock that it knew was unsuitable for the job. :)

> One can also decide the clock with the kernel command line. Should we
> update that message to also say:
> 
>   Or set the global clock via the kernel command line with
>   "trace_clock=global"
> 
> ?

Sure, I was mainly floating the idea of trying to pick sensible
defaults. Unstable clocks are quite rare nowadays, the ones we have in
the lab are a pair of Core2 Duo.
-Chris