public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: tglx@linutronix.de, linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: [PATCH] Allow Intel platforms to declare unsynchronized TSC to kernel
Date: Wed, 24 Mar 2010 06:32:57 +0100	[thread overview]
Message-ID: <20100324053257.GA4088@basil.fritz.box> (raw)

Allow Intel platforms to declare unsynchronized TSC to kernel

[This came out of a private discussion with Linus last week]

Nehalem class processors support the CONSTANT_TSC bit in the 8000_0007 CPUID
leaf to declare CONSTANT_TSC. One of the ideas behind this bit was to allow the 
platform to clear it when it cannot guarantee a constant TSC.

Unfortunately this doesn't work right now because the Intel CPU
initialization also checks the model number and assumes that
all CPUs newer than Yonah have CONSTANT_TSC too.

Terminate the model number check before Nehalem and rely on the 8000_0007
bit only on newer CPUs. This way the platform can actually turn it off.

Atom CPUs might also have newer model numbers and do not necessarily
have that bit, but they are all single socket and expected to always
have synchronous TSCs.

Open: the two checks still differ in setting sched_clock_stable. 

Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
 arch/x86/kernel/cpu/intel.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Index: linux-2.6.34-rc1-ak/arch/x86/kernel/cpu/intel.c
===================================================================
--- linux-2.6.34-rc1-ak.orig/arch/x86/kernel/cpu/intel.c	2010-03-03 02:01:27.000000000 +0100
+++ linux-2.6.34-rc1-ak/arch/x86/kernel/cpu/intel.c	2010-03-24 06:16:42.000000000 +0100
@@ -43,8 +43,16 @@
 		}
 	}
 
+	/*
+	 * On Nehalem+ class we trust the CONSTANT_TSC bit in 8000_0007 edx,
+	 * so that a platform that doesn't have synchronized TSCs can clear it.
+ 	 * Older CPUs didn't set that bit, so we keep hard coding the model
+	 * numbers for those.
+ 	 * Note this matches Atom class too, but there the TSCs are always
+	 * synchronized anyways.
+ 	 */
 	if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
-		(c->x86 == 0x6 && c->x86_model >= 0x0e))
+		(c->x86 == 0x6 && c->x86_model >= 0x0e && c->x86_model < 0x1a))
 		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
 
 #ifdef CONFIG_X86_64

             reply	other threads:[~2010-03-24  5:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-24  5:32 Andi Kleen [this message]
2010-03-29  7:46 ` [PATCH] Allow Intel platforms to declare unsynchronized TSC to kernel Andi Kleen
2010-03-29  9:43   ` Hidetoshi Seto
2010-03-29 10:47     ` Andi Kleen

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=20100324053257.GA4088@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@osdl.org \
    /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