Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1586731 > unrolled thread

Re: [GIT pull] x86/timers for 4.10

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [GIT pull] x86/timers for 4.10 Mike Galbraith <efault@gmx.de> - 2017-02-23 09:30 +0100
    Re: [GIT pull] x86/timers for 4.10 Peter Zijlstra <peterz@infradead.org> - 2017-02-23 10:20 +0100
    Re: [GIT pull] x86/timers for 4.10 Borislav Petkov <bp@suse.de> - 2017-02-23 11:30 +0100
      Re: [GIT pull] x86/timers for 4.10 Mike Galbraith <efault@gmx.de> - 2017-02-23 14:40 +0100

#1586731 — Re: [GIT pull] x86/timers for 4.10

On Thu, 2017-02-09 at 16:07 +0100, Thomas Gleixner wrote:
> On Wed, 8 Feb 2017, Mike Galbraith wrote:
> > On Wed, 2017-02-08 at 12:44 +0100, Thomas Gleixner wrote:
> > > On Mon, 6 Feb 2017, Olof Johansson wrote:
> > > > [    0.177102] [Firmware Bug]: TSC ADJUST differs: Reference
> > > > CPU0:
> > > > -6495898515190607 CPU1: -6495898517158354
> > > 
> > > Yay, another "clever" BIOS ....
> > 
> > Oh yeah, that reminds me...
> > 
> > I met one such box, and the adjustment code did salvage it, but I
> > had
> > to cheat a little for it to do so reliably, as it would sometimes
> > still
> > see a delta of 1 or 2 whole cycles, and hand me a useless wreck
> > instead
> > quick like bunny big box.
> 
> Can you share your cheatery ?

I can do better than that... sorta ;-)

x86/tsc: Fix unreliable tsc adjust

On a 4 socket BIOS challenged box (4x18), the magic number '3' does
not work reliably, resulting in TSC being disabled more often than not.

Replace defective magic number '3' with functional magic number '5',
derived via scientific method number sockets in afflicted box, plus
one for good luck, and reboot box a lot to validate (poke 'n' hope).

Signed-off-by: Mike Galbraith <efault@gmx.de>
---
 arch/x86/kernel/tsc_sync.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -294,7 +294,7 @@ void check_tsc_sync_source(int cpu)
 	if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
 		atomic_set(&test_runs, 1);
 	else
-		atomic_set(&test_runs, 3);
+		atomic_set(&test_runs, 5);
 retry:
 	/*
 	 * Wait for the target to start or to skip the test:

[toc] | [next] | [standalone]

#1586767

On Thu, Feb 23, 2017 at 09:20:06AM +0100, Mike Galbraith wrote:
> On Thu, 2017-02-09 at 16:07 +0100, Thomas Gleixner wrote:

> > Can you share your cheatery ?
> 
> I can do better than that... sorta ;-)
> 
> x86/tsc: Fix unreliable tsc adjust
> 
> On a 4 socket BIOS challenged box (4x18), the magic number '3' does
> not work reliably, resulting in TSC being disabled more often than not.
> 
> Replace defective magic number '3' with functional magic number '5',
> derived via scientific method number sockets in afflicted box, plus
> one for good luck, and reboot box a lot to validate (poke 'n' hope).
> 
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> ---
>  arch/x86/kernel/tsc_sync.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/arch/x86/kernel/tsc_sync.c
> +++ b/arch/x86/kernel/tsc_sync.c
> @@ -294,7 +294,7 @@ void check_tsc_sync_source(int cpu)
>  	if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
>  		atomic_set(&test_runs, 1);
>  	else
> -		atomic_set(&test_runs, 3);
> +		atomic_set(&test_runs, 5);
>  retry:
>  	/*
>  	 * Wait for the target to start or to skip the test:

Confirmed on another box too; the default of 3 wasn't sufficient to
achieve sync. When upping it to 16, sync was achieved in around 4 runs
or so.

[toc] | [prev] | [next] | [standalone]

#1586797

On Thu, Feb 23, 2017 at 09:20:06AM +0100, Mike Galbraith wrote:
> --- a/arch/x86/kernel/tsc_sync.c
> +++ b/arch/x86/kernel/tsc_sync.c
> @@ -294,7 +294,7 @@ void check_tsc_sync_source(int cpu)
>  	if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
>  		atomic_set(&test_runs, 1);
>  	else
> -		atomic_set(&test_runs, 3);
> +		atomic_set(&test_runs, 5);

So
		atomic_set(&test_runs, max_t(unsigned int, 3, num_online_nodes() + 1));

:-)

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1586895

On Thu, 2017-02-23 at 11:26 +0100, Borislav Petkov wrote:
> On Thu, Feb 23, 2017 at 09:20:06AM +0100, Mike Galbraith wrote:
> > --- a/arch/x86/kernel/tsc_sync.c
> > +++ b/arch/x86/kernel/tsc_sync.c
> > @@ -294,7 +294,7 @@ void check_tsc_sync_source(int cpu)
> >  > > 	> > if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
> >  > > 	> > 	> > atomic_set(&test_runs, 1);
> >  > > 	> > else
> > -> > 	> > 	> > atomic_set(&test_runs, 3);
> > +> > 	> > 	> > atomic_set(&test_runs, 5);
> 
> So
> 	> 	> atomic_set(&test_runs, max_t(unsigned int, 3, num_online_nodes() + 1));

I don't know that there is a correlation, ergo the "log" wording ;-)

	-Mike

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web