Received: by 10.213.65.68 with SMTP id h4csp351694imn; Fri, 30 Mar 2018 06:51:04 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+GVEAMOfafobGzhBttBf4Wo12+Q/cJLclL6WlDb5D3Xd5Tfh6US6X4WHT7OIWKKUp+SZFA X-Received: by 2002:a17:902:9045:: with SMTP id w5-v6mr13108616plz.287.1522417864649; Fri, 30 Mar 2018 06:51:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522417864; cv=none; d=google.com; s=arc-20160816; b=nZFpbHSDHa3ZfmvG8lAtn93nMmXlejZ5N66l90VfYWRPGleUwn5DDFjXyp6BgvCUty H97fSr0Zz+5Jh716eqeJteUu46byqz9cBjl56XXg0R7bBEeoghc+yFHrUoTeJqQ2/hLT +K2rJj2M04biPGSA2MUAXD+Y5q5mFdBtllR04Xz/DURKKltIZcGFHa8YCsoZk0ZvXe3J 85gkRpcI0DQ3f6ZKr3iecUpuJzjqQkp45pvZkVFbkMlo8+sHQ3e/UsaffGdcDuTKlO5S 5xuMMRZmoKgIf0IL0acoxOLtX77g/dlDlPaVmhHJgMi1B5p53na2RT1Hkh41xVl4EN5g jpPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=OKQDegzdKIgFZay/3hEwPye7W62diFuiHcZqQPC/xQM=; b=khmTBoxPMNtFvOPheVwyXc2V/NUEWUKmxt0cWQBk+ctF1JxaQa8uP9v+hyRwGgJqhv nCHVQU92ejmlsWKclhJatAZEQN5EzhU7qFNCJgsOxt4fQ4xF+qUBXGSYz17m7ZDTxXtf DHNQHtFGhNsdo4LedgAiVYHWa5/3Olsq221OHYUnVgHtLjNBEs6vx8VJdL6bYVJ4V17L 8CSWIDjBcT0Xw23p5SXc6Y4w3Nabvi79qIBYVaOnqukqfl+hv0YWp/ci/T1Ygu28G2Hv /etlhlaeVnfwNJsCEbJtUWfP2H6EOVfi4jyJBFhlscmN6TgBXcOyN+TOkL7+TlA9J5IM YQfg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1-v6si8203894pld.267.2018.03.30.06.50.40; Fri, 30 Mar 2018 06:51:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751324AbeC3Nst (ORCPT + 99 others); Fri, 30 Mar 2018 09:48:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:59472 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbeC3Nss (ORCPT ); Fri, 30 Mar 2018 09:48:48 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2D17D217A8; Fri, 30 Mar 2018 13:48:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D17D217A8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Fri, 30 Mar 2018 09:48:45 -0400 From: Steven Rostedt To: Chris Wilson Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org Subject: Re: [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable Message-ID: <20180330094845.068a9a81@gandalf.local.home> In-Reply-To: <20180329222557.6274-1-chris@chris-wilson.co.uk> References: <20180329222557.6274-1-chris@chris-wilson.co.uk> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Mar 2018 23:25:57 +0100 Chris Wilson 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. 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" ? -- Steve > > Signed-off-by: Chris Wilson > Cc: Steven Rostedt (VMware) > --- > kernel/trace/trace.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 13baf85b27d8..c5462513db90 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -41,6 +41,7 @@ > #include > #include > #include > +#include > #include > > #include "trace.h" > @@ -8505,3 +8506,15 @@ __init static int clear_boot_tracer(void) > > fs_initcall(tracer_init_tracefs); > late_initcall_sync(clear_boot_tracer); > + > +#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK > +__init static int tracing_set_default_clock(void) > +{ > + /* sched_clock_stable() is determined in late_initcall */ > + if (!trace_boot_clock && !sched_clock_stable()) > + tracing_set_clock(&global_trace, "global"); > + > + return 0; > +} > +late_initcall_sync(tracing_set_default_clock); > +#endif