Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756757Ab2BGJuP (ORCPT ); Tue, 7 Feb 2012 04:50:15 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:54595 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756619Ab2BGJuN (ORCPT ); Tue, 7 Feb 2012 04:50:13 -0500 Date: Tue, 7 Feb 2012 10:50:00 +0100 From: Ingo Molnar To: Borislav Petkov Cc: Venki Pallipadi , Peter Zijlstra , Stephane Eranian , linux-kernel@vger.kernel.org, acme@redhat.com, robert.richter@amd.com, eric.dumazet@gmail.com, Andreas Herrmann Subject: Re: [BUG] perf: perf sched warning possibly due to clock granularity on AMD Message-ID: <20120207095000.GF15359@elte.hu> References: <20120206153408.GA31237@aftab> <1328546246.2482.10.camel@laptop> <20120206164626.GA31704@aftab> <1328547259.2482.11.camel@laptop> <20120206202722.GA556@aftab> <1328560293.2482.24.camel@laptop> <20120206203738.GB556@aftab> <20120207083253.GC12821@elte.hu> <20120207090609.GB4852@aftab> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120207090609.GB4852@aftab> User-Agent: Mutt/1.5.21 (2010-09-15) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1803 Lines: 46 * Borislav Petkov wrote: > On Tue, Feb 07, 2012 at 09:32:53AM +0100, Ingo Molnar wrote: > > > Yes. If these two flags are set, TSC should be consistent and > > > sched_clock_stable could be set and it will be reset if there > > > is a call to mark_tsc_unstable(). > > > > Most of the details swapped out from my brain meanwhile, but I > > have some vague memories of a DMI quirk for some high-end system > > that just did a sched_clock_stable = 0 or such. > > > > So if the common case is that the TSC is entirely synchronized > > across CPUs, then we can default to that and rely on platform > > initialization code or DMI quirks setting the few large-NUMA > > systems to an unstable TSC. > > There's also 14be1f7454ea96ee614467a49cf018a1a383b189 which removed > the setting of sched_clock_stable to 1 due to UV systems not being > TSC-synchronized across blades. > > I guess, we could tentatively enable it on AMD provided nothing has > marked the TSC as unstable already: > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index f4773f4..ddee619 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -456,6 +456,8 @@ static void __cpuinit early_init_amd(struct cpuinfo_x86 *c) > if (c->x86_power & (1 << 8)) { > set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); > set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC); > + if (!check_tsc_unstable()) > + sched_clock_stable = 1; > } i'd go for that. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/