Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp841987rwd; Thu, 15 Jun 2023 02:52:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6iotUN5rhssl/H2qvEwG1/PONojwiWOGaF4z/UQf1wiv5B1qnpiJmZLKtVpYlX4B3sgOiW X-Received: by 2002:a05:6a00:17a7:b0:666:41bd:5088 with SMTP id s39-20020a056a0017a700b0066641bd5088mr6375317pfg.13.1686822732873; Thu, 15 Jun 2023 02:52:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686822732; cv=none; d=google.com; s=arc-20160816; b=oSaqwzRl8K4+qZFTOIp2C8g6kptfPEAUBlO2q1t5CBuRYwZpZjzmx/6oxXV6mHx392 oHf/Lw+sPB5Hj2Ph7O2zWzDgzWNKAHbBSsDb7mAN0GEzWARhKbJIcRBPhD6fzGS3eEWj ZmXQpR+i0GUYeyY5hi+v0UzCDAHhFdiZ+6LYz9pCqES003Cdp0mId2FyQaEPtmOys8uo UGvua88Gb4B91VGUBTVfxAIGFPAu1RsoFSUd71jTzcLKKDbwtYTbXGrOKdfAKVxfJblI 3BWX/1rtFOoyBxi8S/+XZR1sdHH8yrgf4e9mn9vNwhZG1RN8PbXdj0Jo80gZ2fvFZVar P9jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=VJf8eYHVYCsVZWGj5WU5NKUE6RcPsFfWXduJSEsZwhw=; b=xEHdb7BVtElYrCQfmDjAMFu2ciqc/szwMox4rCr8K/8cG758XM56JvZ+mohTrO/xQW VuUercT97YC3ySodd/hN9hgiG/jnxH9lS9SpSn55/9kco/cUWgk9djwHCwDcPVUB9Ata aPvEajvDHKsg9ftNiePzVJw7xvk7F8JBOV47oUjp50QahPfFABsuQBAKnAi+yOnTspjT EMeDdRgwaAm2mG1THaEvzr8rAUbRZK4XfYx6+xfl8zrjcQbSSoWdSyNwQfQyMDwAajGA uiI+kC4y6MdP5Flv9zPpYqtpgtpoOYrPwCxSqEHRlGTOWt3XclLvmL+I07xtCTQyOhAm 2sKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=adNoPsIf; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k12-20020aa79d0c000000b00646479e5702si12556799pfp.381.2023.06.15.02.52.01; Thu, 15 Jun 2023 02:52:12 -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=@infradead.org header.s=casper.20170209 header.b=adNoPsIf; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239272AbjFOJUk (ORCPT + 99 others); Thu, 15 Jun 2023 05:20:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237158AbjFOJUj (ORCPT ); Thu, 15 Jun 2023 05:20:39 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FCE419B5 for ; Thu, 15 Jun 2023 02:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=VJf8eYHVYCsVZWGj5WU5NKUE6RcPsFfWXduJSEsZwhw=; b=adNoPsIf3rftxigO9zc1H9H3bO Co9nWpcn9ca7+/d4bP/HGUKbaNYil5WVCj9XR/HD5i/q0y8r66zISHqUvqSakM/7JUn+kAkNUytJl 0NsbFm7M1ysAYE0qoM0bcIjnMfAhFwvO5B93fsrYdt2wY9w1rfv2ibOKh9epStSQv9piUOyWRU5rx QGsBrSHjoZvjXT/YxiHn9n7kfwKqWrMsL0oy5BWCSmibK9q5XTMgwDPU/mBiqqW+msuxbNiQe8NVW mS5u6bo1G6eCE1sWmD02QTlw8IdbwP7IilA2X0Dr1yDyXa2b/BXPB6EhjR74CFQh+93fOneV4P6mk dp9hxO/Q==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1q9j9T-007R8Y-2J; Thu, 15 Jun 2023 09:20:23 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 78B6F3002A9; Thu, 15 Jun 2023 11:20:21 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5DDA3265FBBD4; Thu, 15 Jun 2023 11:20:21 +0200 (CEST) Date: Thu, 15 Jun 2023 11:20:21 +0200 From: Peter Zijlstra To: Feng Tang Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , David Woodhouse , "Paul E . McKenney" , x86@kernel.org, linux-kernel@vger.kernel.org, rui.zhang@intel.com, tim.c.chen@intel.com Subject: Re: [Patch v2 2/2] x86/tsc: use logical_packages as a better estimation of socket numbers Message-ID: <20230615092021.GE1683497@hirez.programming.kicks-ass.net> References: <20230613052523.1106821-1-feng.tang@intel.com> <20230613052523.1106821-2-feng.tang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230613052523.1106821-2-feng.tang@intel.com> 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_NONE,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 On Tue, Jun 13, 2023 at 01:25:23PM +0800, Feng Tang wrote: > Commit b50db7095fe0 ("x86/tsc: Disable clocksource watchdog for TSC > on qualified platorms") was introduced to solve problem that > sometimes TSC clocksource is wrongly judged as unstable by watchdog > like 'jiffies', HPET, etc. > > In it, the hardware socket number is a key factor for judging whether > to disable the watchdog for TSC, and 'nr_online_nodes' was chosen as > an estimation due to it is needed in early boot phase before > registering 'tsc-early' clocksource, where all none-boot CPUs are not > brought up yet. > > In recent patch review, Dave and Rui pointed out there are many cases > in which 'nr_online_nodes' is not accurate, like: > > * numa emulation (numa=fake=4 etc.) > * numa=off > * platforms with CPU-less HBM nodes, CPU-less Optane memory nodes. > * SNC (sub-numa cluster) mode enabled > * 'nr_cpus=' and 'maxcpus=' kernel cmdline parameter setup > > Peter Zijlstra suggested 'logical_packages', and it seems to be the > best option we have as it covers all the cases above except the > last one. But it is only usable after smp_init() and all CPUs are > brought up, while 'tsc-early' is initialized before that. > > One solution is to skip the watchdog for 'tsc-early' clocksource, > and move the check after smp_init(), while before 'tsc' clocksource > is registered, where 'logical_packages' could be used. > > For 'nr_cpus' and 'maxcpus' cmdline case, the global flag > 'package_count_unreliable' will be set to true and the watchdog > will be kept as is. So I have at least two machines where I boot with 'possible_cpus=#' because the BIOS MADT is reporting a stupid number of CPUs that aren't actually there. So I think I'm lucky and side-stepped this nonsense, but if someone were to use nr_cpus= for this same purpose, they get screwed over and get the watchdog. Sad day for them I suppose. I realize there might not be a perfect solution, but I'm also struggling to see the value of the whole package_count_unreliable thing.