From: Borislav Petkov <bp@amd64.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>,
linux-kernel@vger.kernel.org, acme@redhat.com, mingo@elte.hu,
robert.richter@amd.com, eric.dumazet@gmail.com,
Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [BUG] perf: perf sched warning possibly due to clock granularity on AMD
Date: Mon, 6 Feb 2012 17:46:26 +0100 [thread overview]
Message-ID: <20120206164626.GA31704@aftab> (raw)
In-Reply-To: <1328546246.2482.10.camel@laptop>
On Mon, Feb 06, 2012 at 05:37:26PM +0100, Peter Zijlstra wrote:
> On Mon, 2012-02-06 at 16:34 +0100, Borislav Petkov wrote:
> > + Andreas.
> >
> > On Mon, Feb 06, 2012 at 03:26:43PM +0100, Peter Zijlstra wrote:
> > > On Mon, 2012-02-06 at 14:25 +0100, Stephane Eranian wrote:
> > > > In summary, two issues:
> > > > - Why is sched_clock_stable not set or even tested on recent AMD systems?
> >
> > AFAICT, sched_clock_stable is set on Intel under the following conditions:
> >
> > /*
> > * c->x86_power is 8000_0007 edx. Bit 8 is TSC runs at constant rate
> > * with P/T states and does not stop in deep C-states.
> > *
> > * It is also reliable across cores and sockets. (but not across
> > * cabinets - we turn it off in that case explicitly.)
> > */
> > 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;
> > }
> >
> > and yes, we can do CONSTANT_TSC and NONSTOP_TSC on the now older F10h
> > already, so Bulldozer can do that too, implicitly.
> >
> > I don't see why sched_clock_stable shouldn't be moved to generic x86
> > code and set based on the two CPUID cap flags above.
>
> stable means more than both those flags together..
>
> - CONSTANT_TSC means freq independent
> - NONSTOP_TSC means it doesn't get stopped in any C state
>
> Together they make TSC completely C-state independent.
> sched_clock_stable actually means that TSC is both _AND_ is consistent
yes.
> across all CPUs in the entire system.
Right, by the "entire system" you mean consistent across cores and
sockets but not necessarily across cabinets, as in the comment above,
correct?
If so, let me ask around if this holds true too.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
next prev parent reply other threads:[~2012-02-06 16:47 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-06 13:25 [BUG] perf: perf sched warning possibly due to clock granularity on AMD Stephane Eranian
2012-02-06 14:26 ` Peter Zijlstra
2012-02-06 14:31 ` Stephane Eranian
2012-02-06 17:17 ` Arnaldo Carvalho de Melo
2012-02-06 15:34 ` Borislav Petkov
2012-02-06 16:37 ` Peter Zijlstra
2012-02-06 16:46 ` Borislav Petkov [this message]
2012-02-06 16:54 ` Peter Zijlstra
2012-02-06 20:27 ` Borislav Petkov
2012-02-06 20:31 ` Peter Zijlstra
2012-02-06 20:37 ` Borislav Petkov
2012-02-06 21:19 ` Venki Pallipadi
2012-02-07 7:51 ` Peter Zijlstra
2012-02-07 8:32 ` Ingo Molnar
2012-02-07 9:06 ` Borislav Petkov
2012-02-07 9:50 ` Ingo Molnar
2012-02-07 12:08 ` [PATCH] x86, AMD: Set sched_clock_stable Borislav Petkov
2012-02-15 15:30 ` Peter Zijlstra
2012-02-07 19:43 ` [tip:perf/core] x86/sched/perf/AMD: " tip-bot for Borislav Petkov
2012-02-08 15:07 ` [BUG] perf: perf sched warning possibly due to clock granularity on AMD Frederic Weisbecker
2012-02-08 15:10 ` Stephane Eranian
2012-02-08 15:22 ` Frederic Weisbecker
2012-02-08 15:23 ` Stephane Eranian
2012-02-18 16:50 ` [PATCH] perf tools: Fix ordering with unstable tsc Frederic Weisbecker
2012-02-22 15:35 ` Stephane Eranian
2012-02-22 15:39 ` David Ahern
2012-03-05 18:43 ` Frederic Weisbecker
2012-03-14 19:55 ` Arnaldo Carvalho de Melo
2012-03-14 20:07 ` David Ahern
2012-03-22 0:10 ` Frederic Weisbecker
2012-03-22 15:28 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120206164626.GA31704@aftab \
--to=bp@amd64.org \
--cc=acme@redhat.com \
--cc=andreas.herrmann3@amd.com \
--cc=eranian@google.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox