Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1165078imd; Thu, 1 Nov 2018 11:11:00 -0700 (PDT) X-Google-Smtp-Source: AJdET5f5c4LQvFqX1tRMf66YJ8ksTtfGvt6GyxyXSKb2tk4HLvCq6rUXdX0UY8R+5Xczf4WGamWN X-Received: by 2002:a63:1342:: with SMTP id 2-v6mr7961201pgt.19.1541095860419; Thu, 01 Nov 2018 11:11:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541095860; cv=none; d=google.com; s=arc-20160816; b=0rc1M0Ebk2pqFw2EVCICtouB4QdWaQ86flCoveknuoftzPelCI2BWX2Nkk6Qauvrj8 Pd3Sq00GYgMXQ+GeYCHNQtka9AsMtcvoRLRsFc8fDe14qqsMROBVGafLjllWsCVvm+4Y Z8UshNxG0ZhmQm0lKmc78Z9AKhDZIk20ERc0Um0tpajoLKvXTU30KzYKOWBiTyeISVBh 5ouNqZSyzAKsfCQ54GkQkzrcnLGOA1r5e0++ZKwHTFtdanYSC1o6bkff1mQ2p03s5D2z PQPh9CSm6ZVjnOZXa/nvc9Td8Uwq/KmxGMLORZ/QpdCvl8gvkN4P30nWYzq55Y/DsQ5q PP3Q== 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=dj172Go2uxqhy72SHsArp3OkMFANsBOYwTn3bVWUp1s=; b=JtVPE/QLvfluB2cbxCt1rit9ym+vTfrQr0lA/jFHLa5KHI+2iAlaDhaG1lZVYykZzX LtjUzLmyrkuv0lep+oAk0QXakKdwvlIDf/gQw90g9iFG+yCetdklxruPyEK7oidaWgl2 8EXT8mGG0D0xD6ZMJIuijUypD0ercZPYooRxmhDsWk1uJn6ML1xEfZKamWmJGIVB+kH8 jLNk1Y+0KKwQi5yby8eNHPvS4+BlSL1LlGzd7uKVi/r9yRO/NgV6HrY9bL7/Y1jM+cmP JmePyk2hvjJe3zT8kpL2UREgTF2dRhVwVgEHYomOo00hB6ntOEmJLleuNlsPd5xD7Lkk uThg== 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 a16-v6si29355411pgw.187.2018.11.01.11.10.39; Thu, 01 Nov 2018 11:11:00 -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 S1727583AbeKBCpT (ORCPT + 99 others); Thu, 1 Nov 2018 22:45:19 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:57860 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726085AbeKBCpS (ORCPT ); Thu, 1 Nov 2018 22:45:18 -0400 Received: from p5492fe24.dip0.t-ipconnect.de ([84.146.254.36] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gIGxp-0007mV-He; Thu, 01 Nov 2018 18:41:01 +0100 Date: Thu, 1 Nov 2018 18:41:00 +0100 (CET) From: Thomas Gleixner To: Miroslav Lichvar cc: John Stultz , Christopher Hall , "H. Peter Anvin" , linux-rt-users , jesus.sanchez-palencia@intel.com, Gavin Hindman , liam.r.girdwood@intel.com, Peter Zijlstra , LKML Subject: Re: TSC to Mono-raw Drift In-Reply-To: <20181024145113.GF12019@localhost> Message-ID: References: <20181015160945.5993-1-christopher.s.hall@intel.com> <20181024145113.GF12019@localhost> 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 Miroslav, On Wed, 24 Oct 2018, Miroslav Lichvar wrote: > On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote: > > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote: > > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote: > > >> On Fri, 19 Oct 2018, John Stultz wrote: > > >>> We might be able to reduce the degree in this case, but I worry the > > >>> extra complexity may only cause problems for others. > > >> > > >> Is it really that complex to add a fixed correction value periodically? > > The error is too large to be corrected by stepping on clock updates. > For a typical TSC frequency we have multiplier in the range of few > millions, so that's a frequency error of up to few hundred ppb. In the > old days when the clock was updated 1000 times per second that would > be hidden in the resolution of the clock, but now with tickless > kernels those steps would be very noticeable. > > If the multiplier was adjusted in the same way as the non-raw clock, > there wouldn't be any steps in time, but there would be steps in > frequency and the time error would be proportional to the update > interval. For a clock updated once per second that's an error of up to > a few hundreds of nanoseconds. That only happens when the system was completely idle for a second and in that case it's a non issue because the clock is updated before it's used. So nothing will be able to observe the time jumping forward by a few or even a few hundreds of nanoseconds. For the regular case, where CPUs are busy and the update happens 100/250/1000 times per second the jump forward will not be noticable at all. > I agree with John. I think the raw monotonic clock should be stable. It is stable. It's still monotonically increasing. > It would help if we better understood the use case. If I needed a > clock that ticks in an exact proportion to the tsc, why wouldn't I use > the tsc directly? Is this about having a fall back in case the tsc > cannot be used (e.g. due to unsynchronized CPUs)? > > If the frequency error was exported, it could be compensated where > necessary. Maybe that would work for the original poster? I'd rather not go there and have yet another magic knob to deal with and we need to have the same thing in the kernel as well. > A better fix might be to modify the calculation of time to use a > second multiplier, effectively increasing its resolution. However, > that would slow down all users of the clock. Right, and we carefully try to avoid that. I really would like to give the adjustment a try. It should solve the problem Christopher cares about and not have any side effects on other users of monotonic raw including NTP/PTP etc. Famous last words .... Thanks, tglx