Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8152332imu; Tue, 4 Dec 2018 03:57:49 -0800 (PST) X-Google-Smtp-Source: AFSGD/WeaL23oQjkbfi5WtdmYs9Nd0cvQmKrEGxc76WrTRvLH2n1zzvshut6QLbnjmrqwpErq6wP X-Received: by 2002:a62:cdd:: with SMTP id 90mr19686543pfm.219.1543924669497; Tue, 04 Dec 2018 03:57:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543924669; cv=none; d=google.com; s=arc-20160816; b=Ng2I/9cOQWp19uxDdDpJDpYsCDxZ1LNPbxOoBs5IhNAMTW48N0enlka/ZBsO2CqqPq 0L9Gtm5rP1dkLFf87dVsckhoCLShXvFB0v+Oo0DB6yT0jMD/Z/Cw2qSgMZ5rfAjvP0L9 cKdfaboCGq1m0HijLMWKLLVDJ8vkiIB2TtuBGwWbNeq/1uSkwQH/vpgMDeADH3bG+IW/ aarE+MuSDGjA5vmOIMtGKBLzXWmbXMlPbIEH+u2fRkVyG0TQEtzZ+k2pyF7s8ITIWJWB 3bClI0CFi/n7YHexzXQNFEJdF94XLV43btEZbQcWEeqGIkjgdlGTjVIf8uQsw/dHHHuT lNHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=exClUXBZ+QJqCWND0/HKzDfpnLhGf/1H4lrVgqsMMX0=; b=Y4zU/4u/IN/burZF82/sDKHxVXTZOxEjkqssarGmxSA4mJqaryaE00kAu3ycMjRrWK 9sxZ/3XdE2vCLSJX7KR5qj8o2ZClsIXv6ry2htTDcrpO07+oDkVmfBZHpGZ49pKIA96Z 3ZDaJbm8TnF0NKYECa1KU5HDYodT3gBy4++WxGAla7NHo3n2I5+nG3iQNEZE/ERmRAwI i88kHXPNitoxlOYRihpocMbQuIcldly8gOZOfOhqu/Kxl+70yXAU3eN4WjAfSxX3oUHM aEomspotafR2AQy2lqm/HbZtslIP4kPOmAqC0GgQdb5fmz/YtKs+1eiBjK3xM0G1ug+t 2VuQ== 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 89si17894114pfr.242.2018.12.04.03.57.34; Tue, 04 Dec 2018 03:57:49 -0800 (PST) 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 S1726151AbeLDL4u (ORCPT + 99 others); Tue, 4 Dec 2018 06:56:50 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:44642 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725767AbeLDL4t (ORCPT ); Tue, 4 Dec 2018 06:56:49 -0500 Received: from conf.hotelmediterraneo.com ([2.228.78.71] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gU9Jm-0004wc-VF; Tue, 04 Dec 2018 12:56:47 +0100 Date: Tue, 4 Dec 2018 12:56:41 +0100 (CET) From: Thomas Gleixner To: Roland Dreier cc: John Stultz , Stephen Boyd , linux-kernel@vger.kernel.org Subject: Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay In-Reply-To: <20181130211750.5571-1-roland@purestorage.com> Message-ID: References: <20181130211750.5571-1-roland@purestorage.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Roland, On Fri, 30 Nov 2018, Roland Dreier wrote: > delta = clocksource_delta(csnow, cs->cs_last, cs->mask); > + > + /* If the cycle delta is beyond what we can safely > + * convert to nsecs, and the watchdog clocksource > + * suggests that we've overslept, skip checking this > + * iteration to avoid marking a clocksource as > + * unstable because of a severely delayed timer. */ /* * Proper multiline comments look like this not like * the above. */ That aside. Why are you trying to do heuristics on the delta? We have way better information than that. The watchdog timer expiry time is known and we can determine the exact delay of the timer. The watchdog clocksource provides the maximum 'idle' time, i.e. the time between two reads, in clocksource::max_idle_ns. That value is filled in when the clocksource is configured. So without doing speculation we can make an informed decision: elapsed = jiffies_to_nsec(jiffies - watchdog_timer->expires) + WATCHDOG_INTERVAL_NS; if (elapsed > wdcs->max_idle_ns) { Skip ...... } Hmm? Thanks, tglx