Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5384152ybi; Tue, 28 May 2019 12:05:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqwIXPcZ24AOV4roRrjcUmy3X+88MApu3JTTITMfh/46cbHl178evs8xdlv83eSI9YdJ+nO/ X-Received: by 2002:a17:902:3103:: with SMTP id w3mr59645477plb.187.1559070352528; Tue, 28 May 2019 12:05:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559070352; cv=none; d=google.com; s=arc-20160816; b=L5LZGgUA4UEGoBQ3mEIMQ0KapD2rukDbYQIiHRqEZUBmUEHs67hgK3D3uyrq7BExHl +5DTvDX/bmMQtz0lwOG/SLohLRYiPPIzhO3gI7ZFXoEFAETKPoM1CiWi96Jn8iFPc1u8 KNLPbirCWRdg/QDOWDkk5uzy1T803zBh7vYESc9/HS0FJNIajUqAoB74UTU7W73rSpSQ QsOlp0+ejrCprNzSDCt7C3WY7PCaNxE5Ssm8lZGF9+hLteb36s8hgoXRaY0XtJHwr7fg xl9U/lH2iNa6ZpAUJjQwkCpZWq9pmfsBf6GCAO3xtQJZFNTw1Sv1BkFYKw+DNiCpb+Vy P/Wg== 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=4opmVIvvs6lqBGcbe153uCPH2dNVuw4OH9UebUcGJAk=; b=pcTEsvuMusWxG4eA/AouVsxVT+fStuyxLMVM7/0wtir6cgPbgw3EgQwmEP11Q89nkr L7u5FV8rBbgCdcsW1+HvPSWRQUgOghL8IXVQVJzW7f2y4Wus73o/jRVAY7mIDLXConwe X+YvPO6ggIg7dPT/mRZyCJmg+MTteM0b26162uKo8Qohmj8iHpkMJt81Ok8VWtEwp/m9 S3R5NKS/iU+dBicYS3yVm9kwframCK+v08I+X7f5PAFhfahI3fmfwOrNxbaKz7ePV2+d ZHKn19aPujYBkxFz8xI7LFtc7icvTMpsU0FbmhOjhzVvln8ELUF5bdV/FIFslJ/wLJNf mGtA== 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 u100si4669625pjb.25.2019.05.28.12.05.36; Tue, 28 May 2019 12:05:52 -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 S1727816AbfE1SBx (ORCPT + 99 others); Tue, 28 May 2019 14:01:53 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:51527 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726576AbfE1SBw (ORCPT ); Tue, 28 May 2019 14:01:52 -0400 Received: from 50-233-100-202-static.hfc.comcastbusiness.net ([50.233.100.202] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hVgQ0-0004i9-OO; Tue, 28 May 2019 20:01:49 +0200 Date: Tue, 28 May 2019 11:01:38 -0700 (PDT) From: Thomas Gleixner To: "Sverdlin, Alexander (Nokia - DE/Ulm)" cc: "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Jason Vas Dias Subject: Re: [PATCH] x86/vdso: implement clock_gettime(CLOCK_MONOTONIC_RAW, ...) In-Reply-To: <20190528080034.31259-1-alexander.sverdlin@nokia.com> Message-ID: References: <20190528080034.31259-1-alexander.sverdlin@nokia.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 Alexander, On Tue, 28 May 2019, Sverdlin, Alexander (Nokia - DE/Ulm) wrote: > Add CLOCK_MONOTONIC_RAW to the existing clock_gettime() vDSO > implementation. This is based on the ideas of Jason Vas Dias and comments > of Thomas Gleixner. Well to some extent, but > The results from the above test program: > > Clock Before After Diff > ----- ------ ----- ---- > CLOCK_MONOTONIC 355531720 338039373 -5% > CLOCK_MONOTONIC_RAW 44831738 336064912 +650% > CLOCK_REALTIME 347665133 338102907 -3% the preformance regressions for CLOCK_MONOTONIC and CLOCK_REALTIME are just not acceptable. > diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c > index 98c7d12..7c9db26 100644 > --- a/arch/x86/entry/vdso/vclock_gettime.c > +++ b/arch/x86/entry/vdso/vclock_gettime.c > @@ -144,6 +144,13 @@ notrace static int do_hres(clockid_t clk, struct timespec *ts) > struct vgtod_ts *base = >od->basetime[clk]; > u64 cycles, last, sec, ns; > unsigned int seq; > + u32 mult = gtod->mult; > + u32 shift = gtod->shift; > + > + if (clk == CLOCK_MONOTONIC_RAW) { > + mult = gtod->raw_mult; > + shift = gtod->raw_shift; > + } They stem from this extra conditional. > > do { > seq = gtod_read_begin(gtod); > @@ -153,8 +160,8 @@ notrace static int do_hres(clockid_t clk, struct timespec *ts) > if (unlikely((s64)cycles < 0)) > return vdso_fallback_gettime(clk, ts); > if (cycles > last) > - ns += (cycles - last) * gtod->mult; > - ns >>= gtod->shift; > + ns += (cycles - last) * mult; And this is completely broken because you read the mult/shift values outside of the sequence count protected region, so a concurrent update of the timekeeping values will lead to inconsistent state. Thanks, tglx