Received: by 10.213.65.68 with SMTP id h4csp228849imn; Tue, 20 Mar 2018 01:50:56 -0700 (PDT) X-Google-Smtp-Source: AG47ELsGqp1xVhwPSkH+AgyvtwT7fdRZEL5fnqG9rVCAZ5NhJcNNMZn+2gVJ/x5qXa2C/jzPZSoc X-Received: by 2002:a17:902:20c9:: with SMTP id v9-v6mr16059802plg.41.1521535856554; Tue, 20 Mar 2018 01:50:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521535856; cv=none; d=google.com; s=arc-20160816; b=Z7b6tfskWtNlaMeGwNTB9vvVMwLopK4o7ylstz501i0aijwYBltxBJ8WgsWxWLIHc8 H3bBq53RsHl+OVhukAwcQSGejvq7s0psnM4IhX9IgSIHA2+n/G0uCArQyn+IRMKPSU/4 FGBk0dP599ceb/RDJUQpiGWyhuP4bjn0usS4ru6/8nYCchmAc//HovUKrhdEoOYEXpPQ u/bXG5SmWHyVyaZS99wzm7SwoA5STePq+bEDUBS9m/zBSIQeYFAF0B0FM8kep6xZZB3e HWCWPB0ayu7k6fo+X9ffCXAHDQcIFJek7Gl8nh5A4m2QzdEkKkuv2PpAD/I38xORFZdr +ehA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=R5GFzSyVefMJzSew45UBjK1T9zAVvneR4h1RxPvoHfo=; b=tPcLHCBLuL4sP+/cUEmkGmrRgYf5AXDzckpKNaQYc0S99MQ8CvZhNm8s3KTTAiS9Od ryHKJht7Dj54wOPzMNFLzpDZILX1jlB0VcPnK1HGxDY1Vh1fZczNMF0Vv6WzbRS7gfQo vDy1XA+xG5cYROTSQtcrglvmhRp+JJ8ZnCWOWJVuG2x0212soTzF1dN5hKbPVLcoTU0e HanILytT5wyI6HesKmSrKdBYVgd6UUq6TznKUmeYycJjpd/AKjrg2yK9RUkLKIwSXwMG uwjdsBor5rnFyZwWOG8/LPKOsGl3rhM02LqvluCn0j/JPJvIYv1sti9veLoAd/DFBpmf N/dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=cJkYYqK6; 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 x14si902632pgq.168.2018.03.20.01.50.38; Tue, 20 Mar 2018 01:50:56 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=cJkYYqK6; 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 S1752142AbeCTItg (ORCPT + 99 others); Tue, 20 Mar 2018 04:49:36 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:40852 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbeCTItf (ORCPT ); Tue, 20 Mar 2018 04:49:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=R5GFzSyVefMJzSew45UBjK1T9zAVvneR4h1RxPvoHfo=; b=cJkYYqK6vz8olGpC6nl9cfyk/ jzl6FHtm3jeYIpXUAlp01l5UOz2bLsa6GsEwVMHmY2k6mKc2zcBF7xfwGsA8nAIb8oOn2kgjpnOBD 1Ywe0W3n1xtOWZihUot89f3geDp3N2Ng4KeCArqrgHiH+C6xmfN+A4mmaXM7cW/EJMsu6VCsbA06r eAB82Yvt6GdjKc9Ln9Cl9oE5eVB6iUwmGugP5nl/KAQbi0/QLztLbPuCImV/Aq+MPu7BRNcoz+YF2 VnIG8ExaslpKbmKv9XkDOt8QAZQLpItKtDAHVh3uX2gq7il/np6uplAoTxxT3Hceh5rknPV7s5kZo Q80ri2q6Q==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1eyCxW-0003Dl-TK; Tue, 20 Mar 2018 08:49:31 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 2C89C202A29FD; Tue, 20 Mar 2018 09:49:29 +0100 (CET) Date: Tue, 20 Mar 2018 09:49:29 +0100 From: Peter Zijlstra To: "Liu, Changcheng" Cc: tglx@linutronix.de, hpa@zytor.com, douly.fnst@cn.fujitsu.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/ioapic: don't use unstable TSC to detect timer IRQ Message-ID: <20180320084929.GP4043@hirez.programming.kicks-ass.net> References: <20180320084255.GA187704@sofia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180320084255.GA187704@sofia> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 20, 2018 at 04:42:55PM +0800, Liu, Changcheng wrote: > In rare case, the TSC is every unstable or can't sync with > real time hardware clock. However did you manage that? Please provide _FAR_ more details. > diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h > index cf5d53c..dcfc5b9 100644 > --- a/arch/x86/include/asm/tsc.h > +++ b/arch/x86/include/asm/tsc.h > @@ -17,6 +17,7 @@ typedef unsigned long long cycles_t; > > extern unsigned int cpu_khz; > extern unsigned int tsc_khz; > +extern int tsc_unstable; > > extern void disable_TSC(void); > > diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c > index 7c55387..0809ec6 100644 > --- a/arch/x86/kernel/apic/io_apic.c > +++ b/arch/x86/kernel/apic/io_apic.c > @@ -1643,7 +1643,7 @@ static int __init timer_irq_works(void) > local_save_flags(flags); > local_irq_enable(); > > - if (boot_cpu_has(X86_FEATURE_TSC)) > + if (boot_cpu_has(X86_FEATURE_TSC) && !tsc_unstable) > delay_with_tsc(); > else > delay_without_tsc(); > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > index fb43027..27b1bae 100644 > --- a/arch/x86/kernel/tsc.c > +++ b/arch/x86/kernel/tsc.c > @@ -36,7 +36,8 @@ EXPORT_SYMBOL(tsc_khz); > /* > * TSC can be unstable due to cpufreq or due to unsynced TSCs > */ > -static int __read_mostly tsc_unstable; > +int __read_mostly tsc_unstable; > +EXPORT_SYMBOL(tsc_unstable); > > /* native_sched_clock() is called before tsc_init(), so > we must start with the TSC soft disabled to prevent No, absolutely not. Even when the TSC is normally deemed unstable, which typically means it is not sync'ed between cores, it is still perfectly suitable to be used for delay loops.