Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp1215238rwe; Fri, 14 Apr 2023 16:45:00 -0700 (PDT) X-Google-Smtp-Source: AKy350amqL/GS1is5EWa7auXfiow/LFKLxuZ3ccuD8pNS1o2NwarDpUf/wI/3BfcRlWJZShgW0u1 X-Received: by 2002:a05:6a00:1a88:b0:635:30fe:4a97 with SMTP id e8-20020a056a001a8800b0063530fe4a97mr10785914pfv.11.1681515900207; Fri, 14 Apr 2023 16:45:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681515900; cv=none; d=google.com; s=arc-20160816; b=hdYtSwB+wVgvNHkQwA022D/4h2CJJPRrMz1WIummkFfxnrQJFAnMiDSaNN0XSDzOr4 oxmcSIAaB9EL+ZTWfmudNQlcfLJQuH1ndFbsHowZ6YnwP2WebPD04psSW4EV6R1EYBDo hFNrv4txGchXvUmPYb2ueERPf+027HmV/QD+RcwNbqmIXXBlAq6OoJ2sgsivjtd0Y8l4 WvkxB7oBMzavbhpHbzhLBHAe8Gdad/O9EkZfB2CKb4n76sfEJXlFmLrWB/7kYBYABii8 Z1tgjdKRlGpQQ6CUDFJSJ9xkq6rCRNeo6FEb9gZr1h4YSnjYf3ZA8xl4w3BtXChf0Qis JE1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:mime-version:references:subject:cc:to:from :dkim-signature:dkim-signature:message-id; bh=IHNUiYT/aa+9U/QrFpO4u8KQro95rDNTw6iEEK5ze9o=; b=JjcVH9ncHy6+RNkLaXwM9V8FR93CEUmPziM0qfCY/aOVARX4i/Gn8vEBSgsJzTqtvB RRQAbhfDAwHrAt+0A+mB8qE/VpKXHR8TBQ8dL7wd2b/PX75QiTvj0U5+PzxU9khrDV9u 8sQWn3hVbrra0mRE1okTo4Ce5DPJRQEXc56LbMT0hLVQ9TnaQpwqjMpAixS+mwNIs5xY 0l4GztMoh+WBCRK0Zjq+m0Zd8ttHpRGnrS+1xpdjJJNBKCWlTFsuoUYdW3C7vyDyp399 7sqP7hirGoyngp4DWG6fkSA451RbLgwoJID7d2P7+dQfqngdKLYW+YcNNmZ5/iavGGTl Krjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=1GGWgmKl; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z22-20020a634c16000000b00513234112a7si5871695pga.883.2023.04.14.16.44.46; Fri, 14 Apr 2023 16:45:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=1GGWgmKl; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229629AbjDNXoZ (ORCPT + 99 others); Fri, 14 Apr 2023 19:44:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229780AbjDNXoV (ORCPT ); Fri, 14 Apr 2023 19:44:21 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E46655243; Fri, 14 Apr 2023 16:44:19 -0700 (PDT) Message-ID: <20230414232309.385574446@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1681515858; 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: references:references; bh=IHNUiYT/aa+9U/QrFpO4u8KQro95rDNTw6iEEK5ze9o=; b=1GGWgmKl+Z16YESLBwfkaJ8pYvl0ibRrRLZ//qbrV6Rn4ejq8Bvi6vo9cC/d06/jSPEXR4 hvZPrEqwgB1nXc44jqzGpA3g8UhwvIHA09SMd8L91BmwlYgaP2m77BjOpifPA2Jp8FR9F+ c0G0jy+fXRMuNBDQtZn5Uv5VCIUDjwdIxXIzMKcFSmEiflIS9qbg0CEGaA9Azgv3qTSjMh 2Q6Nmfsfu+SPkBhJwKselmJZVd9FCtpTg9fyXFZ6j2n8kUoisHbXRgCmcH48m/s4qcThpJ o2FriQZJckk/vdgmu5g5vmRYvkI+K74QUFnLD6JN3zpP58uh1nfGpXn5o7XkuA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1681515858; 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: references:references; bh=IHNUiYT/aa+9U/QrFpO4u8KQro95rDNTw6iEEK5ze9o=; b=cHgI8T+6dl0c5QvmY+jPTGI3Fml5ooLABkADGz2XWt8RyEwXHfElCQYbWkrIndZHTvvRK5 Onzbq0bjdDoTP8Dg== From: Thomas Gleixner To: LKML Cc: x86@kernel.org, David Woodhouse , Andrew Cooper , Brian Gerst , "Arjan van de Veen" , Paolo Bonzini , Paul McKenney , Tom Lendacky , Sean Christopherson , Oleksandr Natalenko , Paul Menzel , "Guilherme G. Piccoli" , Piotr Gorski , David Woodhouse , Usama Arif , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, Russell King , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Guo Ren , linux-csky@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E.J. Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , linux-riscv@lists.infradead.org, Mark Rutland , Sabin Rapan Subject: [patch 03/37] x86/smpboot: Avoid pointless delay calibration is TSC is synchronized References: <20230414225551.858160935@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Date: Sat, 15 Apr 2023 01:44:18 +0200 (CEST) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When TSC is synchronized across sockets then there is no reason in calibrating the delay for the first CPU which comes up on a socket. Just reuse the existing calibration value. This removes 100ms pointlessly wasted time from CPU hotplug. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/smpboot.c | 38 ++++++++++++++++++++++++-------------- arch/x86/kernel/tsc.c | 20 ++++++++++++++++---- 2 files changed, 40 insertions(+), 18 deletions(-) --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -178,10 +178,7 @@ static void smp_callin(void) */ apic_ap_setup(); - /* - * Save our processor parameters. Note: this information - * is needed for clock calibration. - */ + /* Save our processor parameters. */ smp_store_cpu_info(cpuid); /* @@ -192,14 +189,6 @@ static void smp_callin(void) ap_init_aperfmperf(); - /* - * Get our bogomips. - * Update loops_per_jiffy in cpu_data. Previous call to - * smp_store_cpu_info() stored a value that is close but not as - * accurate as the value just calculated. - */ - calibrate_delay(); - cpu_data(cpuid).loops_per_jiffy = loops_per_jiffy; pr_debug("Stack at about %p\n", &cpuid); wmb(); @@ -212,8 +201,24 @@ static void smp_callin(void) cpumask_set_cpu(cpuid, cpu_callin_mask); } +static void ap_calibrate_delay(void) +{ + /* + * Calibrate the delay loop and update loops_per_jiffy in cpu_data. + * smp_store_cpu_info() stored a value that is close but not as + * accurate as the value just calculated. + * + * As this is invoked after the TSC synchronization check, + * calibrate_delay_is_known() will skip the calibration routine + * when TSC is synchronized across sockets. + */ + calibrate_delay(); + cpu_data(smp_processor_id()).loops_per_jiffy = loops_per_jiffy; +} + static int cpu0_logical_apicid; static int enable_start_cpu0; + /* * Activate a secondary processor. */ @@ -240,10 +245,15 @@ static void notrace start_secondary(void /* otherwise gcc will move up smp_processor_id before the cpu_init */ barrier(); + /* Check TSC synchronization with the control CPU: */ + check_tsc_sync_target(); + /* - * Check TSC synchronization with the boot CPU: + * Calibrate the delay loop after the TSC synchronization check. + * This allows to skip the calibration when TSC is synchronized + * across sockets. */ - check_tsc_sync_target(); + ap_calibrate_delay(); speculative_store_bypass_ht_init(); --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1598,10 +1598,7 @@ void __init tsc_init(void) #ifdef CONFIG_SMP /* - * If we have a constant TSC and are using the TSC for the delay loop, - * we can skip clock calibration if another cpu in the same socket has already - * been calibrated. This assumes that CONSTANT_TSC applies to all - * cpus in the socket - this should be a safe assumption. + * Check whether existing calibration data can be reused. */ unsigned long calibrate_delay_is_known(void) { @@ -1609,6 +1606,21 @@ unsigned long calibrate_delay_is_known(v int constant_tsc = cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC); const struct cpumask *mask = topology_core_cpumask(cpu); + /* + * If TSC has constant frequency and TSC is synchronized across + * sockets then reuse CPU0 calibration. + */ + if (constant_tsc && !tsc_unstable) + return cpu_data(0).loops_per_jiffy; + + /* + * If TSC has constant frequency and TSC is not synchronized across + * sockets and this is not the first CPU in the socket, then reuse + * the calibration value of an already online CPU on that socket. + * + * This assumes that CONSTANT_TSC is consistent for all CPUs in a + * socket. + */ if (!constant_tsc || !mask) return 0;