From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751344AbdJDSvD (ORCPT ); Wed, 4 Oct 2017 14:51:03 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:58835 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751066AbdJDSvC (ORCPT ); Wed, 4 Oct 2017 14:51:02 -0400 Date: Wed, 4 Oct 2017 20:50:20 +0200 (CEST) From: Thomas Gleixner To: Mike Travis cc: Peter Zijlstra , Ingo Molnar , "H. Peter Anvin" , Bin Gao , Prarit Bhargava , Dimitri Sivanich , Andrew Banman , Russ Anderson , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 4/5] x86/kernel: Provide a means to disable TSC ART In-Reply-To: Message-ID: References: <20171002151214.822224274@stormcage.americas.sgi.com> <20171002151217.095807201@stormcage.americas.sgi.com> <20171004092704.mm4q5ivrlfrcj6sk@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Oct 2017, Mike Travis wrote: > On 10/4/2017 2:27 AM, Peter Zijlstra wrote: > > On Mon, Oct 02, 2017 at 10:12:18AM -0500, mike.travis@hpe.com wrote: > > > static void detect_art(void) > > > { > > > unsigned int unused[2]; > > > - if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF) > > > + if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF || tsc_art_disabled) > > > return; > > > /* Don't enable ART in a VM, non-stop TSC and TSC_ADJUST > > > required */ > > > > > > So why can't we use is_uv_system() here an for the tsc_adjust thing? > > I could. I just thought that there may be future system arches that > need the same facility? > > > > Also (and I hate the name) tsc_multi_sync_resets is the reason you > > cannot use ART, I don't think it makes sense to introduce yet another > > knob. > > > Okay. I wasn't sure if there might be different causes for wanting one > condition over the other. So does this mean change this later test to > use is_uv_system() or tsc_multi_sync_resets? tsc_multi_sync_resets because that's the reason to disable ART as not all sockets have the same TSC <-> ART offset. Btw, your changelog is slightly wrong here: > On systems where multiple chassis are reset asynchronously there is not a > constant ratio between the ART frequency and the TSC time that can be > provided by the boot cpu. The ratio is actually the same as the frequencies should be the same. Though the offset in that equation: n TSC = offset + ART * --- d is different because that offset is basically TSC_ADJUST. Thanks, tglx