Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6030377iob; Tue, 10 May 2022 08:50:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwU+yq5bb/C81CPRYbajXwKbTSb4VG7mJOxZqWBS5zSDq4I83sscvju2K796nbVr3AMnHXn X-Received: by 2002:aa7:d8d2:0:b0:425:e22b:35c0 with SMTP id k18-20020aa7d8d2000000b00425e22b35c0mr24154470eds.181.1652197812254; Tue, 10 May 2022 08:50:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652197812; cv=none; d=google.com; s=arc-20160816; b=SbnwFDrbSSWqsbyC93mUit55/Qt1ycN3j2bR6DbyiX9AhL+TFhpgZbu6ZelM/mkhL5 1pQS8VDDxNMefbNsBeS/Jjs8hXnLOvemQ2WJ02BeZdjY+JlHclYUSNa0JajnU4Wb5YpV Cf1/mj+NIs3tam0CsumPwNO7D/sXNvmdN+AnNsI5Cjy3nC8VweNCQEKAMhXneH7Vydgo v9/SkLESnzcQ7kVDZe2hwU8LjixWQz7PR31Dvl9IqAmJTIC7haG3j7PZ7clJ2az9CZrP 6IpfFtyxrHusSTklssykqa2Ylww534cKEN8+2fwGs4HjzepZyWmjzBRcub662ryTA5vH znLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=Js8RDp7iMnj24JVY5ETKpHQgMOnO+QR2UvUOw/t3NVI=; b=Vu8hg3xkMP2reWLJmogNAP+akaHMWh4l2Fw4/favVpditW2P3vD5JXp/ExYya0t6JH wcABM4vQ1/FKaFfN/0NovCxyCV0uNIOYTJNMI7cPqjW3yupJnZsGWPH6loHhHn+6eGit ikDMSyau4loZ1Bf0pOOkfuSE7YzERtwmoCK141ZHWkSi36vxICsWkkAyKmtuA/J56YPl Nlnz8csRJ0FBIbTa6f52Vh8++20T7FB5kV4xkbRedY7Id+peICmcV9+8sM0WRpHCqpss /39x/vFZx982nAUAj9qdLSOVQor6oBo2mz3DPKmMkLm0Zz/j9f3/ZrIk9CFeIdNPryx3 SAGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=iiIyquw+; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=wrd2WsMh; 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 x19-20020a50f193000000b004259316bbbfsi15255068edl.359.2022.05.10.08.49.48; Tue, 10 May 2022 08:50: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=@linutronix.de header.s=2020 header.b=iiIyquw+; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=wrd2WsMh; 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 S241174AbiEJLsF (ORCPT + 99 others); Tue, 10 May 2022 07:48:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236537AbiEJLsE (ORCPT ); Tue, 10 May 2022 07:48:04 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53DEE2044D3 for ; Tue, 10 May 2022 04:44:07 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652183045; 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=Js8RDp7iMnj24JVY5ETKpHQgMOnO+QR2UvUOw/t3NVI=; b=iiIyquw+8QYZcovxorjqRFjfwhtMfLsHJEqe7bb762UGT/v/l/uDU2MlyH5t4U6gak6twB cCyHPEaUDEHU0enPu0J4DBw0J15rjARHL269aYiMpCupYu3BwyjP2tKIEcoTzzuFT76fSs Z0yC68PLfuFj70wdQZ68UUH/P13qMaOf9EUpMqUg6EgaWEupFN2HWfhg6OWSZyr0hg/ZGt Qzi4v4cd/H7wytmGiF+HHWJ9XcNU3cDxrdhX3LKr8Dq8hqBErcTwz/b/6JL8w7xTiMyZdu TWiYR1JW/491ynSImOymZIIK8iEtjvf2oz1jdx2qz/HmDYNZXQ9LjnzhjQSgpg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652183045; 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=Js8RDp7iMnj24JVY5ETKpHQgMOnO+QR2UvUOw/t3NVI=; b=wrd2WsMhhsrFIarhn4h+pO3O6mNNt4p+QTgQfzqOJMhou7WWpPXvvVvQJWm3tmm+PLi6JN 3qRFd4zzo70zIfDQ== To: Nicholas Piggin , Ricardo Neri , x86@kernel.org Cc: Andi Kleen , Andrew Morton , Lu Baolu , David Woodhouse , Stephane Eranian , iommu@lists.linux-foundation.org, Joerg Roedel , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "Ravi V. Shankar" , Ricardo Neri , Suravee Suthikulpanit , Tony Luck Subject: Re: [PATCH v6 28/29] x86/tsc: Restart NMI watchdog after refining tsc_khz In-Reply-To: <1652180070.1r874kr0tg.astroid@bobo.none> References: <20220506000008.30892-1-ricardo.neri-calderon@linux.intel.com> <20220506000008.30892-29-ricardo.neri-calderon@linux.intel.com> <1652180070.1r874kr0tg.astroid@bobo.none> Date: Tue, 10 May 2022 13:44:05 +0200 Message-ID: <87ilqdpq7u.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain 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,URIBL_BLOCKED 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, May 10 2022 at 21:16, Nicholas Piggin wrote: > Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am: >> + /* >> + * If in use, the HPET hardlockup detector relies on tsc_khz. >> + * Reconfigure it to make use of the refined tsc_khz. >> + */ >> + lockup_detector_reconfigure(); > > I don't know if the API is conceptually good. > > You change something that the lockup detector is currently using, > *while* the detector is running asynchronously, and then reconfigure > it. What happens in the window? If this code is only used for small > adjustments maybe it does not really matter but in principle it's > a bad API to export. > > lockup_detector_reconfigure as an internal API is okay because it > reconfigures things while the watchdog is stopped [actually that > looks untrue for soft dog which uses watchdog_thresh in > is_softlockup(), but that should be fixed]. > > You're the arch so you're allowed to stop the watchdog and configure > it, e.g., hardlockup_detector_perf_stop() is called in arch/. > > So you want to disable HPET watchdog if it was enabled, then update > wherever you're using tsc_khz, then re-enable. The real question is whether making this refined tsc_khz value immediately effective matters at all. IMO, it does not because up to that point the watchdog was happily using the coarse calibrated value and the whole use TSC to assess whether the HPET fired mechanism is just a guestimate anyway. So what's the point of trying to guess 'more correct'. Thanks, tglx