linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Borislav Petkov <bp@amd64.org>,
	Venki Pallipadi <venki@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stephane Eranian <eranian@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Robert Richter <robert.richter@amd.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Andreas Herrmann <andreas.herrmann3@amd.com>,
	Borislav Petkov <bp@alien8.de>
Subject: [PATCH] x86, AMD: Set sched_clock_stable
Date: Tue,  7 Feb 2012 13:08:52 +0100	[thread overview]
Message-ID: <1328616532-13783-1-git-send-email-bp@alien8.de> (raw)
In-Reply-To: <20120207095000.GF15359@elte.hu>

Stephane Eranian reported that doing a scheduler latency measurements
with perf on AMD doesn't work out as expected due to the fact that the
sched_clock() granularity is too coarse, i.e. done in jiffies due to the
sched_clock_stable not set, which, if set, would mean that we get to use
the TSC as sample source which would give us much higher precision.

However, there's no reason not to set sched_clock_stable on AMD because
all families from F10h and upwards do have an invariant TSC and have the
CPUID flag to prove (CPUID_8000_0007_EDX[8]).

Make it so, #1.

Signed-off-by: Borislav Petkov <bp@alien8.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/20120206132546.GA30854@quad
---
 arch/x86/kernel/cpu/amd.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f4773f4..0a44b90 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -5,6 +5,7 @@
 #include <linux/mm.h>
 
 #include <linux/io.h>
+#include <linux/sched.h>
 #include <asm/processor.h>
 #include <asm/apic.h>
 #include <asm/cpu.h>
@@ -456,6 +457,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;
 	}
 
 #ifdef CONFIG_X86_64
-- 
1.7.9


  reply	other threads:[~2012-02-07 12:09 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
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                         ` Borislav Petkov [this message]
2012-02-15 15:30                           ` [PATCH] x86, AMD: Set sched_clock_stable 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=1328616532-13783-1-git-send-email-bp@alien8.de \
    --to=bp@alien8.de \
    --cc=acme@infradead.org \
    --cc=andreas.herrmann3@amd.com \
    --cc=bp@amd64.org \
    --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 \
    --cc=venki@google.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;
as well as URLs for NNTP newsgroup(s).