Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp602930imm; Wed, 20 Jun 2018 03:44:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLSc/o1mfVan9V+tZvEdcgEBIi+EF5+ZmRfKpMYYhYP3Rg7vR0IFcjK7fgNL+uQauQoAbqt X-Received: by 2002:aa7:83d1:: with SMTP id j17-v6mr22411520pfn.236.1529491446149; Wed, 20 Jun 2018 03:44:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529491446; cv=none; d=google.com; s=arc-20160816; b=LOc9vNLwO1jkUT7NQEgjgRRjIrS7vARMqNDfA/M79U3hgt2UMEGTHz+531htP7pagm NsvHUn+SnNlL+s+/aQ8W2sGe4aX/0iVxYaLjzP6Aj74AlXQeA62hIdAU836ofNFiIxBW UT9UiQdUGPkO6qu5+6Oaav6REoFboyRzu6Pd/1K/E5/sXIbIIhrKt/rgH6mRtaOBkzEk HLN3VLG4jca1oKCEtox2C7CphqAqfFOeeJNIXssFeyenpJvVdVynJQ0zsdw6IPNRuwEH sQAdCfn3+MkEXlIJV8Gu2O5Akvv1plsAWHwwXhSuQ1IAaJSBuKqrfj2y00utGsJSJ6Kd QWeQ== 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 :arc-authentication-results; bh=zwoCkcggL8lVYipJg0uOum35O4+vD688Z4twA0va2Tk=; b=oYiNBekEQwrieygvcNtxGnGA0A09YOaFLUNadtIgseLz5nV/4ZnvvWLRizOU1TUgH+ gs8j0XCywWJq6MLgjY/z4LQdRm8gHQiCeS1HTjFVoj5s8Iv7Kjbb2E35+p4bnMVPxIs3 0de58/ilTQBSooviUNjaRiuzp0JM4BDDCWhXJVAsKvijuUabnHYGz6jK8a0Iqq8Swc44 fYcCZM5ya2mnBEHMmFE/oYVYWJcWbZLm8bDP7FHKztdAlWzN1/j8Oe4R6HxspwTsJFX0 jOjCr4JixrvUJ5Gnec/Sp/InYH7COXKd0o0Qc56pGMNvk9PdZ1WhZKYbmd3h9NDpY4jI qvcQ== 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 63-v6si2071526pfx.61.2018.06.20.03.43.51; Wed, 20 Jun 2018 03:44:06 -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 S1754134AbeFTKnE (ORCPT + 99 others); Wed, 20 Jun 2018 06:43:04 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:59844 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752650AbeFTKnD (ORCPT ); Wed, 20 Jun 2018 06:43:03 -0400 Received: from p4fea482e.dip0.t-ipconnect.de ([79.234.72.46] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fVaZU-0003Wm-Sl; Wed, 20 Jun 2018 12:42:41 +0200 Date: Wed, 20 Jun 2018 12:42:40 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: Pavel Tatashin , steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux@armlinux.org.uk, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, john.stultz@linaro.org, sboyd@codeaurora.org, x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com, douly.fnst@cn.fujitsu.com, prarit@redhat.com, feng.tang@intel.com, pmladek@suse.com, gnomes@lxorguk.ukuu.org.uk Subject: Re: [PATCH v10 7/7] x86/tsc: use tsc early In-Reply-To: <20180620091532.GK2476@hirez.programming.kicks-ass.net> Message-ID: References: <20180615174204.30581-1-pasha.tatashin@oracle.com> <20180615174204.30581-8-pasha.tatashin@oracle.com> <20180620091532.GK2476@hirez.programming.kicks-ass.net> 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 On Wed, 20 Jun 2018, Peter Zijlstra wrote: > On Wed, Jun 20, 2018 at 01:52:10AM +0200, Thomas Gleixner wrote: > > u64 native_sched_clock(void) > > { > > + if (static_branch_likely(&__use_tsc)) > > + return cycles_2_ns(rdtsc()); > > > > + if (static_branch_unlikely(&tsc_early_enabled)) { > > + if (tsc_early_sched_clock) > > + return cycles_2_ns(rdtsc()); > > } > > I'm still puzzled by the entire need for tsc_early_enabled and all that. > Esp. since both branches do the exact same thing: > > return cycles_2_ns(rdtsc()); Right. But up to the point where the real sched_clock initialization can be done and the static keys can be flipped, there must be a way to conditinally use TSC depending on availablility and early initialization. We cannot make the __use_tsc key TRUE at conmpile timeunless we add an extra conditional into that codepath which makes the whole static key moot. So the second static key for the early stuff is TRUE and has the extra conditional: if (tsc_early_sched_clock) return cycles_2_ns(rdtsc()); And that code path gets nuked with flipping the key to FALSE in the later init code, so that in case of jiffies we do not have the extra conditional in every sched_clock() invocation. You might argue, that we shouldn't care becasue the jiffies case is just the worst case fallback anyway. I wouldn't even disagree as those old machines which have TSC varying with the CPU frequency really should not matter anymore. Pavel might disagree of course. Thanks, tglx