Received: by 10.213.65.68 with SMTP id h4csp2482440imn; Mon, 2 Apr 2018 08:20:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/yn9EUirqE6OxQ1g7Qd2lrSWQtp+hE5NZlfGbhlKUNnzZGmX2H0lLdcfiD0DE6/VxUIlF8 X-Received: by 10.101.98.193 with SMTP id m1mr6779256pgv.248.1522682412906; Mon, 02 Apr 2018 08:20:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522682412; cv=none; d=google.com; s=arc-20160816; b=qn33j/EE8W/bs1hCf9JiFsrXTipX53xsP8oZ+MMuwYFYB037/YCffMxEB8J5vfFsOk 0YZgc/hsRtwZFXYPG13AFmntbZtNo4cPNuSLvkSGgMkMy+ieO282bpahYp5SM/rkrnpG 4FFAFM3WM+WdapAb0fMmpbjxndAU5kUMZKivyLJbCBGtNXcxV2BA+KmPKBgyZjAwe8MB G7Q6joMcLswkl9+bxhYWxpsfahbqH8t6xCkCM32myC+W3JtgLu9vKul45Hl6oFtJBZpn G7OFoVGK/STKNEfjmr9SbGZPoXYaXEB3Ac9KCdd2SZ2TIa6ytjeusD0RihpCsaItFq0Y QEgg== 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=zmmbrwEJ8VHl6+zv4BB5F5nAkxvLZjvrIApqfBKjSZc=; b=wSUpyZbYxFzBic9rdKG3aZP+SfJkQHc5342/XcJp19dLljzN0XFJsy0E87tDcIG5d5 eldH1pVPTxhtC8GcuP98Ae87akdNRZsZC7rIVx6GIBIPuHxTRjiGdVZnuRS3bUAzHT2U i7t5MNEAdbywOqfBbdyhzcGsYOg/TiTHP+0+Yq13EZ28oRmOczBqtUAMVHfPAiHzDDec AknIZ8oOUMmsPtkHirAva1QtLauZdh2dxXeearR0ZfhKAoGhNlqiyYRUypXR5n5XaJhC sXM8BoPKw3sK+pr5jSwhtSla6jB2aqH+WSJYMZDF1BwznZzSt/1tT6gqeG8BdKRTouBn u5XA== 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 l128si339434pgl.248.2018.04.02.08.19.58; Mon, 02 Apr 2018 08:20:12 -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 S1752246AbeDBPRk (ORCPT + 99 others); Mon, 2 Apr 2018 11:17:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:32922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbeDBPRj (ORCPT ); Mon, 2 Apr 2018 11:17:39 -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 AA82B20838; Mon, 2 Apr 2018 15:17:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA82B20838 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: Mon, 2 Apr 2018 11:17:36 -0400 From: Steven Rostedt To: Chris Wilson Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org Subject: Re: [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable Message-ID: <20180402111736.763c861e@gandalf.local.home> In-Reply-To: <20180330150132.16903-1-chris@chris-wilson.co.uk> References: <20180330150132.16903-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 Fri, 30 Mar 2018 16:01:31 +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 > > Signed-off-by: Chris Wilson > Cc: Steven Rostedt (VMware) > --- > v2: Tell the user what's happening and what they can do to correct it. > Thanks, I pulled them in. I'll start testing them before I post to git. -- Steve