Quoting Steven Rostedt (2018-03-30 14:48:45) > On Thu, 29 Mar 2018 23:25:57 +0100 > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
