Messages in this thread | | | Date | Tue, 7 Feb 2012 10:50:00 +0100 | From | Ingo Molnar <> | Subject | Re: [BUG] perf: perf sched warning possibly due to clock granularity on AMD |
| |
* Borislav Petkov <bp@amd64.org> 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
| |