linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
@ 2015-05-31  5:44 Len Brown
  2015-06-01 18:40 ` Andy Lutomirski
  0 siblings, 1 reply; 9+ messages in thread
From: Len Brown @ 2015-05-31  5:44 UTC (permalink / raw)
  To: x86, linux-pm, linux-kernel; +Cc: Len Brown

From: Len Brown <len.brown@intel.com>

Speed cpu_up() by believing CPUID's "invariant TSC" flag,
and skipping the TSC warp test on single socket systems.

On my desktop, cpu_up() duration drops from 4.4ms to 2.4ms.
That savings is per-CPU, and occurs during boot, online
and resume from S3.

Originally, this was done for all sized systems, in Feb-2009
by 83ce40092868 (x86: set X86_FEATURE_TSC_RELIABLE).

But in Dec-2009, it was disabled for all sized systems by
6c56ccecf05f (x86: Reenable TSC sync check at boot, even with NONSTOP_TSC)
due to discovery of a TSC time warp on a multi-node system.

Here we re-enable this optimization for single-socket systems.

Multi-node systems will still run the sanity test.

"tsc=reliable" is still available to tell them to not bother.

Perhaps in the future we can up the node count to 2, or perhaps 4,
using dmi_check_multi[] to workaround bugs, per the original design.

Signed-off-by: Len Brown <len.brown@intel.com>
---
 arch/x86/kernel/cpu/intel.c | 21 +++++++++++++++------
 arch/x86/kernel/tsc.c       |  2 +-
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 50163fa..aa00390 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -79,17 +79,26 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 		c->x86_phys_bits = 36;
 
 	/*
-	 * 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.)
+	 * c->x86_power is CPUID(0x80000007).EDX
+	 * Bit 8 describes the "invariant TSC" feature, where the TSC
+	 * continues running at a constant rate across P/T/C states.
+	 * Linux X86_FEATURE_CONSTANT_TSC describes the constant rate.
+	 * Linux X86_FEATURE_NONSTOP_TSC describes not stopping in C-states.
+	 * Linux X86_FEATURE_TSC_RELIABLE means that Linux should skip
+	 * TSC sanity checks because we know the TSC is sufficient for
+	 * clocksource.  This was invented for VMM use, but can also
+	 * be used to skip sanity check cost on bare metal.
+	 * We set it here, but the TSC code currently tests anyway
+	 * on multi-node systems, out of paranoia.
+	 * dmi_check_multi[] can also be used to clear this flag.
 	 */
 	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())
+		if (!check_tsc_unstable()) {
 			set_sched_clock_stable();
+			set_cpu_cap(c, X86_FEATURE_TSC_RELIABLE);
+		}
 	}
 
 	/* Penwell and Cloverview have the TSC which doesn't sleep on S3 */
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 5054497..f1a25e5 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1014,7 +1014,7 @@ static void __init check_system_tsc_reliable(void)
 	if (res_low & RTSC_SUSP)
 		tsc_clocksource_reliable = 1;
 #endif
-	if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE))
+	if (boot_cpu_has(X86_FEATURE_TSC_RELIABLE) && (nr_node_ids == 1))
 		tsc_clocksource_reliable = 1;
 }
 
-- 
2.4.1.314.g9532ead


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-05-31  5:44 [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID Len Brown
@ 2015-06-01 18:40 ` Andy Lutomirski
  2015-06-02  0:45   ` Len Brown
  0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2015-06-01 18:40 UTC (permalink / raw)
  To: Len Brown, x86, linux-pm, linux-kernel; +Cc: Len Brown

On 05/30/2015 10:44 PM, Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
>
> Speed cpu_up() by believing CPUID's "invariant TSC" flag,
> and skipping the TSC warp test on single socket systems.

I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" 
with a "X79A-GD65 (8D) (MS-7760)" motherboard.  (DO NOT BUY THAT 
MOTHERBOARD!)

The brilliant stock firmware breaks TSC sync on bootup.  Even with the 
updated firmware I'm using, it's broken on resume from S3.

If you want to make this depend on X86_FEATURE_TSC_ADJUST and confirm 
that all cores have the same IA32_TSC_ADJUST value, then maybe that 
would be okay.  Otherwise, please don't underestimate the malice^Wgross 
incompetence of firmware vendors.

--Andy

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-01 18:40 ` Andy Lutomirski
@ 2015-06-02  0:45   ` Len Brown
  2015-06-02  1:12     ` Andy Lutomirski
  2015-06-04  7:17     ` H. Peter Anvin
  0 siblings, 2 replies; 9+ messages in thread
From: Len Brown @ 2015-06-02  0:45 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: X86 ML, Linux PM list, linux-kernel, Len Brown

On Mon, Jun 1, 2015 at 2:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On 05/30/2015 10:44 PM, Len Brown wrote:
>>
>> From: Len Brown <len.brown@intel.com>
>>
>> Speed cpu_up() by believing CPUID's "invariant TSC" flag,
>> and skipping the TSC warp test on single socket systems.
>
>
> I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" with a
> "X79A-GD65 (8D) (MS-7760)" motherboard.  (DO NOT BUY THAT MOTHERBOARD!)
>
> The brilliant stock firmware breaks TSC sync on bootup.  Even with the
> updated firmware I'm using, it's broken on resume from S3.

So the stock firmware broke the TSC on boot _and_ S3.
The updated firmware does not break the TSC on boot, but still breaks it on S3?

For this board, please send the output from
$ dmesg | grep -i tsc

I would think we could detect this issue much faster than requesting
the full 2ms test.

> If you want to make this depend on X86_FEATURE_TSC_ADJUST and confirm that
> all cores have the same IA32_TSC_ADJUST value, then maybe that would be
> okay.

That suggestion sounds reasonable.

BTW, it also begs the question if Linux could actually *repair* the BIOS damage?

thanks,
Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-02  0:45   ` Len Brown
@ 2015-06-02  1:12     ` Andy Lutomirski
  2015-06-03 19:03       ` Len Brown
  2015-06-04  7:17     ` H. Peter Anvin
  1 sibling, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2015-06-02  1:12 UTC (permalink / raw)
  To: Len Brown; +Cc: Andy Lutomirski, X86 ML, Linux PM list, linux-kernel, Len Brown

On Mon, Jun 1, 2015 at 5:45 PM, Len Brown <lenb@kernel.org> wrote:
> On Mon, Jun 1, 2015 at 2:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> On 05/30/2015 10:44 PM, Len Brown wrote:
>>>
>>> From: Len Brown <len.brown@intel.com>
>>>
>>> Speed cpu_up() by believing CPUID's "invariant TSC" flag,
>>> and skipping the TSC warp test on single socket systems.
>>
>>
>> I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" with a
>> "X79A-GD65 (8D) (MS-7760)" motherboard.  (DO NOT BUY THAT MOTHERBOARD!)
>>
>> The brilliant stock firmware breaks TSC sync on bootup.  Even with the
>> updated firmware I'm using, it's broken on resume from S3.
>
> So the stock firmware broke the TSC on boot _and_ S3.
> The updated firmware does not break the TSC on boot, but still breaks it on S3?

Exactly.

>
> For this board, please send the output from
> $ dmesg | grep -i tsc

[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 3199.952 MHz processor
[    0.192253] TSC deadline timer enabled
[    1.712495] tsc: Refined TSC clocksource calibration: 3199.960 MHz
[    2.712791] Switched to clocksource tsc

... suspend and resume ...

[   61.414518] TSC synchronization [CPU#0 -> CPU#1]:
[   61.414518] Measured 6137255520 cycles TSC warp between CPUs,
turning off TS clock.
[   61.414522] tsc: Marking TSC unstable due to check_tsc_sync_source failed

>
> I would think we could detect this issue much faster than requesting
> the full 2ms test.
>
>> If you want to make this depend on X86_FEATURE_TSC_ADJUST and confirm that
>> all cores have the same IA32_TSC_ADJUST value, then maybe that would be
>> okay.
>
> That suggestion sounds reasonable.
>
> BTW, it also begs the question if Linux could actually *repair* the BIOS damage?

Quite possibly.  Is there such thing as a single-socket CPU that
claims invariant CPU on which setting TSC_ADJUST to zero on all cores
won't result in a synchronized TSC?  (This is moot for my CPU.  I
don't have TSC_ADJUST.)

On a somewhat related note, why are we still calibrating the TSC
frequency based on the PIT?  intel_pstate appears to know how to read
it off directly.

--Andy

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-02  1:12     ` Andy Lutomirski
@ 2015-06-03 19:03       ` Len Brown
  2015-06-08 23:24         ` Andy Lutomirski
  0 siblings, 1 reply; 9+ messages in thread
From: Len Brown @ 2015-06-03 19:03 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Andy Lutomirski, X86 ML, Linux PM list, linux-kernel, Len Brown

On Mon, Jun 1, 2015 at 9:12 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Jun 1, 2015 at 5:45 PM, Len Brown <lenb@kernel.org> wrote:
>> On Mon, Jun 1, 2015 at 2:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>> On 05/30/2015 10:44 PM, Len Brown wrote:
>>>>
>>>> From: Len Brown <len.brown@intel.com>
>>>>
>>>> Speed cpu_up() by believing CPUID's "invariant TSC" flag,
>>>> and skipping the TSC warp test on single socket systems.
>>>
>>>
>>> I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" with a
>>> "X79A-GD65 (8D) (MS-7760)" motherboard.  (DO NOT BUY THAT MOTHERBOARD!)
>>>
>>> The brilliant stock firmware breaks TSC sync on bootup.  Even with the
>>> updated firmware I'm using, it's broken on resume from S3.
>>
>> So the stock firmware broke the TSC on boot _and_ S3.
>> The updated firmware does not break the TSC on boot, but still breaks it on S3?
>
> Exactly.
>
>>
>> For this board, please send the output from
>> $ dmesg | grep -i tsc
>
> [    0.000000] tsc: Fast TSC calibration using PIT
> [    0.000000] tsc: Detected 3199.952 MHz processor
> [    0.192253] TSC deadline timer enabled
> [    1.712495] tsc: Refined TSC clocksource calibration: 3199.960 MHz
> [    2.712791] Switched to clocksource tsc
>
> ... suspend and resume ...
>
> [   61.414518] TSC synchronization [CPU#0 -> CPU#1]:
> [   61.414518] Measured 6137255520 cycles TSC warp between CPUs,
> turning off TS clock.
> [   61.414522] tsc: Marking TSC unstable due to check_tsc_sync_source failed


If you boot this machine with "tsc=reliable", to disable the cpu_up
check_tsc_sync,
what happens?  Does the run-time clocksource code detect the bogus TSC values?
If yes, how long does that take?

>> I would think we could detect this issue much faster than requesting
>> the full 2ms test.
>>
>>> If you want to make this depend on X86_FEATURE_TSC_ADJUST and confirm that
>>> all cores have the same IA32_TSC_ADJUST value, then maybe that would be
>>> okay.
>>
>> That suggestion sounds reasonable.
>>
>> BTW, it also begs the question if Linux could actually *repair* the BIOS damage?
>
> Quite possibly.  Is there such thing as a single-socket CPU that
> claims invariant CPU on which setting TSC_ADJUST to zero on all cores
> won't result in a synchronized TSC?  (This is moot for my CPU.  I
> don't have TSC_ADJUST.)
>
> On a somewhat related note, why are we still calibrating the TSC
> frequency based on the PIT?  intel_pstate appears to know how to read
> it off directly.

Okay, so it seems that TSC_ADJUST isn't going to help us here,
as it is independent of this problem.

thanks,
Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-02  0:45   ` Len Brown
  2015-06-02  1:12     ` Andy Lutomirski
@ 2015-06-04  7:17     ` H. Peter Anvin
  2015-06-06 16:12       ` Andy Lutomirski
  1 sibling, 1 reply; 9+ messages in thread
From: H. Peter Anvin @ 2015-06-04  7:17 UTC (permalink / raw)
  To: Len Brown, Andy Lutomirski; +Cc: X86 ML, Linux PM list, linux-kernel, Len Brown

On 06/01/2015 05:45 PM, Len Brown wrote:
> 
> BTW, it also begs the question if Linux could actually *repair* the BIOS damage?
> 

We may very well be able to by setting the TSC offset register to zero
on all CPUs.

	-hpa



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-04  7:17     ` H. Peter Anvin
@ 2015-06-06 16:12       ` Andy Lutomirski
  0 siblings, 0 replies; 9+ messages in thread
From: Andy Lutomirski @ 2015-06-06 16:12 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Len Brown, Andy Lutomirski, X86 ML, Linux PM list, linux-kernel,
	Len Brown

On Thu, Jun 4, 2015 at 12:17 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 06/01/2015 05:45 PM, Len Brown wrote:
>>
>> BTW, it also begs the question if Linux could actually *repair* the BIOS damage?
>>
>
> We may very well be able to by setting the TSC offset register to zero
> on all CPUs.

What TSC offset register?  IIRC before Ivy Bridge (i.e. TSC_ADJUST),
there's a writable TSC register but no visible offset register.

--Andy

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-03 19:03       ` Len Brown
@ 2015-06-08 23:24         ` Andy Lutomirski
  2015-06-09  8:15           ` Thomas Gleixner
  0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2015-06-08 23:24 UTC (permalink / raw)
  To: Len Brown; +Cc: Andy Lutomirski, X86 ML, Linux PM list, linux-kernel, Len Brown

On Wed, Jun 3, 2015 at 12:03 PM, Len Brown <lenb@kernel.org> wrote:
> On Mon, Jun 1, 2015 at 9:12 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Mon, Jun 1, 2015 at 5:45 PM, Len Brown <lenb@kernel.org> wrote:
>>> On Mon, Jun 1, 2015 at 2:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>> On 05/30/2015 10:44 PM, Len Brown wrote:
>>>>>
>>>>> From: Len Brown <len.brown@intel.com>
>>>>>
>>>>> Speed cpu_up() by believing CPUID's "invariant TSC" flag,
>>>>> and skipping the TSC warp test on single socket systems.
>>>>
>>>>
>>>> I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" with a
>>>> "X79A-GD65 (8D) (MS-7760)" motherboard.  (DO NOT BUY THAT MOTHERBOARD!)
>>>>
>>>> The brilliant stock firmware breaks TSC sync on bootup.  Even with the
>>>> updated firmware I'm using, it's broken on resume from S3.
>>>
>>> So the stock firmware broke the TSC on boot _and_ S3.
>>> The updated firmware does not break the TSC on boot, but still breaks it on S3?
>>
>> Exactly.
>>
>>>
>>> For this board, please send the output from
>>> $ dmesg | grep -i tsc
>>
>> [    0.000000] tsc: Fast TSC calibration using PIT
>> [    0.000000] tsc: Detected 3199.952 MHz processor
>> [    0.192253] TSC deadline timer enabled
>> [    1.712495] tsc: Refined TSC clocksource calibration: 3199.960 MHz
>> [    2.712791] Switched to clocksource tsc
>>
>> ... suspend and resume ...
>>
>> [   61.414518] TSC synchronization [CPU#0 -> CPU#1]:
>> [   61.414518] Measured 6137255520 cycles TSC warp between CPUs,
>> turning off TS clock.
>> [   61.414522] tsc: Marking TSC unstable due to check_tsc_sync_source failed
>
>
> If you boot this machine with "tsc=reliable", to disable the cpu_up
> check_tsc_sync,
> what happens?  Does the run-time clocksource code detect the bogus TSC values?
> If yes, how long does that take?

They didn't detect it in the time I watched it.

[    0.000000] Command line: rd.md=0 rd.dm=0
rd.lvm.lv=vg_amaluto_2014/root  KEYTABLE=us
rd.luks.uuid=luks-1dd64d38-40c0-4e20-ad67-aa2590991023 SYSFONT=True ro
root=/dev/mapper/vg_amaluto_2014-root LANG=en_US.UTF-8 rhgb quiet
modprobe.blacklist=nvidia tsc=reliable
[    0.000000] Kernel command line: rd.md=0 rd.dm=0
rd.lvm.lv=vg_amaluto_2014/root  KEYTABLE=us
rd.luks.uuid=luks-1dd64d38-40c0-4e20-ad67-aa2590991023 SYSFONT=True ro
root=/dev/mapper/vg_amaluto_2014-root LANG=en_US.UTF-8 rhgb quiet
modprobe.blacklist=nvidia tsc=reliable
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 3200.188 MHz processor
[    0.186542] TSC deadline timer enabled
[    0.312543] Skipped synchronization checks as TSC is reliable.
[    1.683795] tsc: Refined TSC clocksource calibration: 3199.967 MHz
[    1.685339] Switched to clocksource tsc
[  147.158279] Skipped synchronization checks as TSC is reliable.
[  149.086532] Skipped synchronization checks as TSC is reliable.
[  149.098287] Skipped synchronization checks as TSC is reliable.
[  149.110045] Skipped synchronization checks as TSC is reliable.
[  149.121809] Skipped synchronization checks as TSC is reliable.
[  149.133186] Skipped synchronization checks as TSC is reliable.
[  149.144560] Skipped synchronization checks as TSC is reliable.
[  149.155948] Skipped synchronization checks as TSC is reliable.
[  149.167349] Skipped synchronization checks as TSC is reliable.
[  149.178758] Skipped synchronization checks as TSC is reliable.
[  149.190186] Skipped synchronization checks as TSC is reliable.


--Andy

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
  2015-06-08 23:24         ` Andy Lutomirski
@ 2015-06-09  8:15           ` Thomas Gleixner
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Gleixner @ 2015-06-09  8:15 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Len Brown, Andy Lutomirski, X86 ML, Linux PM list, linux-kernel,
	Len Brown

On Mon, 8 Jun 2015, Andy Lutomirski wrote:
> On Wed, Jun 3, 2015 at 12:03 PM, Len Brown <lenb@kernel.org> wrote:
> > If you boot this machine with "tsc=reliable", to disable the cpu_up
> > check_tsc_sync,
> > what happens?  Does the run-time clocksource code detect the bogus TSC values?
> > If yes, how long does that take?
> 
> They didn't detect it in the time I watched it.

Which is not surprising as the run-time check is disabled with the
reliable flag as well.

        if (tsc_clocksource_reliable)
                clocksource_tsc.flags &= ~CLOCK_SOURCE_MUST_VERIFY;

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-06-09  8:15 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-31  5:44 [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID Len Brown
2015-06-01 18:40 ` Andy Lutomirski
2015-06-02  0:45   ` Len Brown
2015-06-02  1:12     ` Andy Lutomirski
2015-06-03 19:03       ` Len Brown
2015-06-08 23:24         ` Andy Lutomirski
2015-06-09  8:15           ` Thomas Gleixner
2015-06-04  7:17     ` H. Peter Anvin
2015-06-06 16:12       ` Andy Lutomirski

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).