Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp24519imm; Tue, 18 Sep 2018 15:47:26 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYwjg/SBE1QIhaUMqqUvTT9qG6yiF2ijqgMkbrynowQzX6fSsBeZfk6DSiq29egdMfRaweE X-Received: by 2002:a62:1314:: with SMTP id b20-v6mr33422104pfj.230.1537310845961; Tue, 18 Sep 2018 15:47:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537310845; cv=none; d=google.com; s=arc-20160816; b=ppbyUfWURAUATMX9D17kTLJKcwr99DCgMh5MnEx9mGiiz/ANLnBbAJiRJQ2L1iudKN qJ76gPqTF5qC6LGLjI9cTMOZktA2H9zqaHmCxr4u47ZjcYpOBo+wLyREZ3NJKTlRuxZF eaalkRy1eWvV0NXxIOp35hQ2ePl1pAdwDtT2tlkd5jjLADVojvF0jWWUf7lR7KTAveli zHLEaOIMZSPNUggUQGStJ5c66qH2Nbv6XrPthZHSa7Ak3TWUSBiU0HNmw2XsWCM+gzam 3uVwCoWE9UmAjuyRgmZ7qcmwgfv2Ux+034tlFKsZoUd5S37iWtA5qP4AjYrTZZzqKIyV BMdg== 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=Wmyq0W/zT1DVACPHO7TpCBsC14g4oA9kzxgOIP8oajk=; b=pUQ2Z/hXSXUCPlMex2AA9Ahy4IRaicANVUCBnNgqe5buzycjybni2fCDfcWWiacHvV eVa2J8eMDyT6Jqxxk/JblvYxywO/hA2LLBNpE1fSFTiND0xviGB0IDYc04EbaBW7xYu4 lST5hdz+K+toJaui11tW250euo3ChTr4XtXuxuRN1iBzpC1f5fYFOxzrZzc3sTNp373j YPDeYvCXksTadMtNN1NlUg9wLre0Sda065WQTJEoh+rB/oiSaNzXMyqqO94Y2rHWLA5l RWrguVlFueBstwEekhP/bkU41EijEDChtP2aUUEgG7YM7gE72DlpsIjIdeSMOEjWV+I2 VD+w== 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 p187-v6si21655645pfp.27.2018.09.18.15.47.06; Tue, 18 Sep 2018 15:47:25 -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 S1726744AbeISEVs (ORCPT + 99 others); Wed, 19 Sep 2018 00:21:48 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:59078 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725875AbeISEVr (ORCPT ); Wed, 19 Sep 2018 00:21:47 -0400 Received: from p5492e4c1.dip0.t-ipconnect.de ([84.146.228.193] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g2Oli-0005c2-Uu; Wed, 19 Sep 2018 00:46:55 +0200 Date: Wed, 19 Sep 2018 00:46:54 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski cc: John Stultz , Andy Lutomirski , LKML , X86 ML , Peter Zijlstra , Matt Rickard , Stephen Boyd , Florian Weimer , "K. Y. Srinivasan" , Vitaly Kuznetsov , devel@linuxdriverproject.org, Linux Virtualization , Paolo Bonzini , Arnd Bergmann , Juergen Gross Subject: Re: [patch 09/11] x86/vdso: Simplify the invalid vclock case In-Reply-To: <863331ED-B04A-4B94-91A2-D34002C9CCDC@amacapital.net> Message-ID: References: <20180914125006.349747096@linutronix.de> <20180914125118.909646643@linutronix.de> <863331ED-B04A-4B94-91A2-D34002C9CCDC@amacapital.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1153053927-1537310814=:1468" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1153053927-1537310814=:1468 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Tue, 18 Sep 2018, Andy Lutomirski wrote: > > On Sep 18, 2018, at 12:52 AM, Thomas Gleixner wrote: > > > >> On Mon, 17 Sep 2018, John Stultz wrote: > >>> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote: > >>> Also, I'm not entirely convinced that this "last" thing is needed at > >>> all. John, what's the scenario under which we need it? > >> > >> So my memory is probably a bit foggy, but I recall that as we > >> accelerated gettimeofday, we found that even on systems that claimed > >> to have synced TSCs, they were actually just slightly out of sync. > >> Enough that right after cycles_last had been updated, a read on > >> another cpu could come in just behind cycles_last, resulting in a > >> negative interval causing lots of havoc. > >> > >> So the sanity check is needed to avoid that case. > > > > Your memory serves you right. That's indeed observable on CPUs which > > lack TSC_ADJUST. > > > > @Andy: Welcome to the wonderful world of TSC. > > > > Do we do better if we use signed arithmetic for the whole calculation? > Then a small backwards movement would result in a small backwards result. > Or we could offset everything so that we’d have to go back several > hundred ms before we cross zero. That would be probably the better solution as signed math would be problematic when the resulting ns value becomes negative. As the delta is really small, otherwise the TSC sync check would have caught it, the caller should never be able to observe time going backwards. I'll have a look into that. It needs some thought vs. the fractional part of the base time, but it should be not rocket science to get that correct. Famous last words... Thanks, tglx --8323329-1153053927-1537310814=:1468--