Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4283577pxu; Tue, 1 Dec 2020 00:39:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJwByQ8RbrUOB4aCVpJwJavPMX0v40gRMww0tEFreAzFIPtflU6lJL2M1KTfDAkcr7mKygEC X-Received: by 2002:a05:6402:312b:: with SMTP id dd11mr1943999edb.308.1606811940018; Tue, 01 Dec 2020 00:39:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606811940; cv=none; d=google.com; s=arc-20160816; b=J1FzVx8xni0a2+gAravlKM6AqzwFHZ/uiLH50jnDyK/9qMWdPZj6n9R3ojkPAPaPMF YkmOPmS/TVih1E8m9sdvahr6+lpfaiMKGJwRP/+nq5tgmR9UOJgW3JYCUgcJ6WE/k806 adGdEKbKyqXcJSxjcT1Ppdwdd8wXPf++qNqPrbKDDTephE21LW/DCZz5Ml4gPssjtGUn hi7K1wgABR7LNiDeVbszhFfu2aEcqtO8ysJCD5jAS0mIu63xo8rj2uvNKvhqEXuyJxAU d19suqASz81DzfMfOT/UAIpfz8wfp+A7pv6rarPk/zz8WLxnFECPaRihomX8w5ABwjxf yE8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=wyZcKrTPNDscrzAEUQTesH16QjDB1/zyUvA4fPNaqfY=; b=bp1CzWPlM8Ri4BS34Tq6/yVX2EdPHo4AMOtiVJ5/t08Z7N9bPEHhLtam7CQcuH6Y75 DknBOCK1SOL0pJbg3iubX3adStUkkcxOJ6JhKluNxKMrtWDVUTHK2Z0OdzuCS6C4FklE 2NABeqrw1pLTLcP4GPp52tRFIFNhyr+t0RK4vBHc1n3IQc3xYdTFFcvZcuMRhmkTNFPQ /YglkzfekcxZnP6pOS+CPt5vJsBCsywZF0AZp0wzrTiBsIEopgnVYb/GTw1o1AziW5VN U0PW4l8Ljy8l3j1n1ow2k/kSEquNDH1AqolBGAZC96A/jz3+B6C5mv/qZHiJdyDk90hF 1Inw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si738237edi.333.2020.12.01.00.38.37; Tue, 01 Dec 2020 00:39:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728722AbgLAIfa (ORCPT + 99 others); Tue, 1 Dec 2020 03:35:30 -0500 Received: from mga01.intel.com ([192.55.52.88]:7906 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727343AbgLAIf3 (ORCPT ); Tue, 1 Dec 2020 03:35:29 -0500 IronPort-SDR: JAwRlSeW35vWh7h5WFqMDW19zGwmmpuC5b0ZNacKUs3TwQ4TPGHEdZ1jwA8exrdAmAgc5J6At/ G2IRy87NNjqw== X-IronPort-AV: E=McAfee;i="6000,8403,9821"; a="190985420" X-IronPort-AV: E=Sophos;i="5.78,384,1599548400"; d="scan'208";a="190985420" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2020 00:34:48 -0800 IronPort-SDR: 4wlBkTRi8+ykZpMr20MHGKn2z5KPNloVqp+R8YUnBQEHhrTlmntmGjat5hvB9IVZpcEkamoWz1 lqBT4ikPsZWQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,384,1599548400"; d="scan'208";a="335001904" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.147.98]) by orsmga006.jf.intel.com with ESMTP; 01 Dec 2020 00:34:44 -0800 Date: Tue, 1 Dec 2020 16:34:43 +0800 From: Feng Tang To: Thomas Gleixner Cc: Bjorn Helgaas , Ingo Molnar , Borislav Petkov , x86@kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Helgaas , Kai-Heng Feng , rui.zhang@intel.com, len.brown@intel.com Subject: Re: [PATCH] x86/PCI: Convert force_disable_hpet() to standard quirk Message-ID: <20201201083443.GA8855@shbuild999.sh.intel.com> References: <20201119181904.149129-1-helgaas@kernel.org> <87v9dtk3j4.fsf@nanos.tec.linutronix.de> <20201126012421.GA92582@shbuild999.sh.intel.com> <87eekfk8bd.fsf@nanos.tec.linutronix.de> <20201127061131.GB105524@shbuild999.sh.intel.com> <87eekairc0.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eekairc0.fsf@nanos.tec.linutronix.de> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, On Mon, Nov 30, 2020 at 08:21:03PM +0100, Thomas Gleixner wrote: > Feng, > > On Fri, Nov 27 2020 at 14:11, Feng Tang wrote: > > On Fri, Nov 27, 2020 at 12:27:34AM +0100, Thomas Gleixner wrote: > >> On Thu, Nov 26 2020 at 09:24, Feng Tang wrote: > >> Yes, that can happen. But OTOH, we should start to think about the > >> requirements for using the TSC watchdog. > >> > >> I'm inclined to lift that requirement when the CPU has: > >> > >> 1) X86_FEATURE_CONSTANT_TSC > >> 2) X86_FEATURE_NONSTOP_TSC > > > >> 3) X86_FEATURE_NONSTOP_TSC_S3 > > IIUC, this feature exists for several generations of Atom platforms, > > and it is always coupled with 1) and 2), so it could be skipped for > > the checking. > > Yes, we can ignore that bit as it's not widely available and not > required to solve the problem. > > >> 4) X86_FEATURE_TSC_ADJUST > >> > >> 5) At max. 4 sockets > >> > >> The only reason I hate to disable HPET upfront at least during boot is > >> that HPET is the best mechanism for the refined TSC calibration. PMTIMER > >> sucks because it's slow and wraps around pretty quick. > >> > >> So we could do the following even on platforms where HPET stops in some > >> magic PC? state: > >> > >> - Register it during early boot as clocksource > >> > >> - Prevent the enablement as clockevent and the chardev hpet timer muck > >> > >> - Prevent the magic PC? state up to the point where the refined > >> TSC calibration is finished. > >> > >> - Unregister it once the TSC has taken over as system clocksource and > >> enable the magic PC? state in which HPET gets disfunctional. > > > > This looks reasonable to me. > > > > I have thought about lowering the hpet rating to lower than PMTIMER, so it > > still contributes in early boot phase, and fades out after PMTIMER is > > initialised. > > Not a good idea. pm_timer is initialized before the refined calibration > finishes. Yes, you are right. I missed the part. I dug some old notes, and found another old case (kernel 3.4) that a broken PMTIMER as the watchdog clocksource wrongly judged TSC to be unstable and disabled it, which makes me agree more to the idea of "lift that requirement when the CPU has ..." If the TSC has those bits to garantee its reliability, then no need to use a less reliable clocksource to monitor it. Thanks, Feng