From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAE15C77B7A for ; Tue, 16 May 2023 20:40:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229949AbjEPUkE (ORCPT ); Tue, 16 May 2023 16:40:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230363AbjEPUjx (ORCPT ); Tue, 16 May 2023 16:39:53 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 658B21BF4 for ; Tue, 16 May 2023 13:39:52 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684269590; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yCVRViIkSyo2p0AVmD2VBFU7NXG7CdGaJTUHpk53BrU=; b=36WTLNP0b8Tfd7PpIDZh6Yf9Q+udTKydU73GAA2jPeqm0kG+CZ6rJvcGRL51MySh3KDp5y UUD7zygPFkj57C3Mw2R1LUYKys3Gmab5bf5s3q5tvMHfRLTfCZSup1wsTvp+fFkf8fGU03 W0CBWDGpBxTO2cp7P50b0IGNC6va1M1l2A6krtyQpXhoT0fAaDAJ0tgdqyi68YFnnT3mOT S0LRL7mGBdXy1MEFW4XzvcFnDbqSfM6woZ68U4dDUlTPyM2pZe4/Y1L6UvL0s2xg6HfWfh fHIwE4hPhsaL62IweXc+4Qj8c7a++U/t6wZmI5JLaSdcPsmQy8pOwbi8uiAWMg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684269590; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yCVRViIkSyo2p0AVmD2VBFU7NXG7CdGaJTUHpk53BrU=; b=wkjjAvff5MwqI1LdgSgL20aU/GxPcU+j0081LoiGfDaVBR7zcdEf+dwFw2DoYBoeh8IXhZ /R5WA8Yq+B36P6Bg== To: "H. Peter Anvin" , Dave Hansen , Rong Tao Cc: Rong Tao , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [PATCH] x86/vdso: Use non-serializing instruction rdtsc In-Reply-To: <4959DDEE-58DC-45E7-BE00-019A45A97D2B@zytor.com> References: <56ea846e-bce8-2508-e485-1dada8c39643@intel.com> <4959DDEE-58DC-45E7-BE00-019A45A97D2B@zytor.com> Date: Tue, 16 May 2023 22:39:49 +0200 Message-ID: <878rdo6mei.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 16 2023 at 10:57, H. Peter Anvin wrote: > On May 16, 2023 7:12:34 AM PDT, Dave Hansen wrote: >>On 5/15/23 23:52, Rong Tao wrote: >>> Replacing rdtscp or 'lfence;rdtsc' with the non-serializable instruction >>> rdtsc can achieve a 40% performance improvement with only a small loss of >>> precision. >> >>I think the minimum that can be done in a changelog like this is to >>figure out _why_ a RDTSCP was in use. There are a ton of things that >>can make the kernel go faster, but not all of them are a good idea. >> >>I assume that the folks that wrote this had good reason for not using >>plain RSTSC. What were those reasons? > > I believe the motivation is that it is atomic with reading the CPU number. Believe belongs in the realm of religion and does not help much to explain technical issues. :) rdtsc_ordered() has actually useful comments and also see: https://lore.kernel.org/lkml/87ttwc73za.ffs@tglx The Intel SDM and the AMD APM are both blury about RDTSC speculation and we've observed (quite some time ago) situations where the RDTSC value was clearly from the past solely due to speculation. So we had to bite the bullet to add the fencing. Preferrably RDTSCP or if not available LFENCE; RDTSC. IIRC the original variant was even CPUID; RDTSC, which is daft. The time readout does (simplified): do { // Wait for the sequence count to become even while ((seq = READ_ONCE(vd->seq)) & 1); tsc = rdtsc_ordered(); now = convert(vd, tsc); } while (seq != READ_ONCE(vd->seq)); It's obviously more complex than that, but you get the idea. Now replace RDTSCP with RDTSC and explain what guarantees that the TSC read isn't speculated ahead of the sequence check. If it's architecturally guaranteed that this can't happen, I'm more than happy to use plain RDTSC. But as I've observed that myself in the past, I'm pretty sure that it is not guaranteed, at least not on older microarchitectures. If newer ones make that guarantee then they should have exposed that as a feature bit in CPUID and clearly documented it in the SDM. As long as that does not happen, I'm sticking to the correctness first principle. Thanks, tglx