Re: huge nanosleep variance on 11-stable

[Konstantin Belousov]

On Wed, Nov 02, 2016 at 06:28:08PM +0200, Konstantin Belousov wrote:
> On Wed, Nov 02, 2016 at 09:18:15AM -0700, Jason Harmening wrote:
> > I think you are probably right.  Hacking out the Intel-specific
> > additions to C-state parsing in acpi_cpu_cx_cst() from r282678 (thus
> > going back to sti;hlt instead of monitor+mwait at C1) fixed the problem
> > for me.  But r282678 also had the effect of enabling C2 and C3 on my
> > system, because ACPI only presents MWAIT entries for those states and
> > not p_lvlx.
> You can do the same with "debug.acpi.disabled=mwait" loader tunable
> without hacking the code. And set sysctl hw.acpi.cpu.cx_lowest to C1 to
> enforce use of hlt instruction even when mwait states were requested.

I believe I now understood the problem.  First, I got the definitive
confirmation that LAPIC timer on Nehalems is stopped in any C mode
higher than C1/C1E, i.e. even if C2 is enabled LAPIC eventtimer cannot
be used.  This is consistent with the ARAT CPUID bit CPUID[0x6].eax[2]
reported zero.

On SandyBridge and IvyBridge CPUs, it seems that ARAT might be both 0
and 1 according to the same source, but all CPUs I saw have ARAT = 1.
And for Haswell and later generations, ARAT is claimed to be always
implemented.

The actual issue is somewhat silly bug, I must admit: if ncpus >= 8, and
non-FSB interrupt routing from HPET, default HPET eventtimer quality 450
is reduced by 100, i.e. it is 350. OTOH, LAPIC default quality is 600
and it is reduced by 200 if ARAT is not reported. We end up with HPET
quality 350 < LAPIC quality 400, despite ARAT is not set.

The patch below sets LAPIC eventtimer quality to 100 if not ARAT.  Also
I realized that there is no reason to disable deadline mode regardless
of ARAT.

diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
index d9a3453..1b1547d 100644
--- a/sys/x86/x86/local_apic.c
+++ b/sys/x86/x86/local_apic.c
@@ -478,8 +478,9 @@ native_lapic_init(vm_paddr_t addr)
lapic_et.et_quality = 600;
if (!arat) {
lapic_et.et_flags |= ET_FLAGS_C3STOP;
-   lapic_et.et_quality -= 200;
-   } else if ((cpu_feature & CPUID_TSC) != 0 &&
+   lapic_et.et_quality = 100;
+   }
+   if ((cpu_feature & CPUID_TSC) != 0 &&
(cpu_feature2 & CPUID2_TSCDLT) != 0 &&
tsc_is_invariant && tsc_freq != 0) {
lapic_timer_tsc_deadline = 1;

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: huge nanosleep variance on 11-stable

[Jason Harmening]

On Fri, Nov 25, 2016 at 1:25 AM, Konstantin Belousov 
wrote:

> On Wed, Nov 02, 2016 at 06:28:08PM +0200, Konstantin Belousov wrote:
> > On Wed, Nov 02, 2016 at 09:18:15AM -0700, Jason Harmening wrote:
> > > I think you are probably right.  Hacking out the Intel-specific
> > > additions to C-state parsing in acpi_cpu_cx_cst() from r282678 (thus
> > > going back to sti;hlt instead of monitor+mwait at C1) fixed the problem
> > > for me.  But r282678 also had the effect of enabling C2 and C3 on my
> > > system, because ACPI only presents MWAIT entries for those states and
> > > not p_lvlx.
> > You can do the same with "debug.acpi.disabled=mwait" loader tunable
> > without hacking the code. And set sysctl hw.acpi.cpu.cx_lowest to C1 to
> > enforce use of hlt instruction even when mwait states were requested.
>
> I believe I now understood the problem.  First, I got the definitive
> confirmation that LAPIC timer on Nehalems is stopped in any C mode
> higher than C1/C1E, i.e. even if C2 is enabled LAPIC eventtimer cannot
> be used.  This is consistent with the ARAT CPUID bit CPUID[0x6].eax[2]
> reported zero.
>
> On SandyBridge and IvyBridge CPUs, it seems that ARAT might be both 0
> and 1 according to the same source, but all CPUs I saw have ARAT = 1.
> And for Haswell and later generations, ARAT is claimed to be always
> implemented.
>
> The actual issue is somewhat silly bug, I must admit: if ncpus >= 8, and
> non-FSB interrupt routing from HPET, default HPET eventtimer quality 450
> is reduced by 100, i.e. it is 350. OTOH, LAPIC default quality is 600
> and it is reduced by 200 if ARAT is not reported. We end up with HPET
> quality 350 < LAPIC quality 400, despite ARAT is not set.
>
> The patch below sets LAPIC eventtimer quality to 100 if not ARAT.  Also
> I realized that there is no reason to disable deadline mode regardless
> of ARAT.
>
> diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
> index d9a3453..1b1547d 100644
> --- a/sys/x86/x86/local_apic.c
> +++ b/sys/x86/x86/local_apic.c
> @@ -478,8 +478,9 @@ native_lapic_init(vm_paddr_t addr)
> lapic_et.et_quality = 600;
> if (!arat) {
> lapic_et.et_flags |= ET_FLAGS_C3STOP;
> -   lapic_et.et_quality -= 200;
> -   } else if ((cpu_feature & CPUID_TSC) != 0 &&
> +   lapic_et.et_quality = 100;
> +   }
> +   if ((cpu_feature & CPUID_TSC) != 0 &&
> (cpu_feature2 & CPUID2_TSCDLT) != 0 &&
> tsc_is_invariant && tsc_freq != 0) {
> lapic_timer_tsc_deadline = 1;
>
> Ah, that makes sense.  Thanks!

I'll try the patch as soon as I get back from vacation.  I've been able to
verify that setting cx_lowest and disabling mwait fixes the problem without
hacking the code.  But I've been too busy at $(WORK) to check anything
else, namely whether forcing HPET would also fix the problem.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Bogus turbo mode with Intel(R) Core(TM)2 Duo CPU P9700 (2.80GHz)

[Jakub Lach]

Hello, 

Since I'm running this CPU, I've noticed there is additional
field in supported frequency (under heavy load)-

dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.freq_levels: 2801/35000 2800/35000 2450/30625 2133/23888
1866/20902 1600/15000 1400/13125 1200/11250 1000/9375 800/12000 700/10500
600/9000 500/7500 400/6000 300/4500 200/3000 100/1500
dev.cpu.0.freq: 2801
dev.cpu.0.temperature: 67,0C

as far as I know, the +1 MHz mode is a turbo boost factory 
overclock, however this CPU does not support it. Anybody knows 
what's going on? 

I've previously had T9400 (2.53 GHz), there was no such thing listed 
and it was running slightly cooler under load, despite having higher 
TDP (however P9700 is a lot cooler when idle, as expected).

Still, I don't think it is possible it's actually being overclocked?



--
View this message in context: 
http://freebsd.1045724.x6.nabble.com/Bogus-turbo-mode-with-Intel-R-Core-TM-2-Duo-CPU-P9700-2-80GHz-tp6147461.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Bogus turbo mode with Intel(R) Core(TM)2 Duo CPU P9700 (2.80GHz)

[Adrian Chadd]

the acpi cpu frequency module just exposes the frequency lis given to
it by ACPI. If your ACPI table exposes the turbo boost frequency but
doesn't implement it on the backend, FreeBSD doesn't know. We just
obey what we're told. :)


-a


On 25 November 2016 at 20:16, Jakub Lach  wrote:
> Hello,
>
> Since I'm running this CPU, I've noticed there is additional
> field in supported frequency (under heavy load)-
>
> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.0.freq_levels: 2801/35000 2800/35000 2450/30625 2133/23888
> 1866/20902 1600/15000 1400/13125 1200/11250 1000/9375 800/12000 700/10500
> 600/9000 500/7500 400/6000 300/4500 200/3000 100/1500
> dev.cpu.0.freq: 2801
> dev.cpu.0.temperature: 67,0C
>
> as far as I know, the +1 MHz mode is a turbo boost factory
> overclock, however this CPU does not support it. Anybody knows
> what's going on?
>
> I've previously had T9400 (2.53 GHz), there was no such thing listed
> and it was running slightly cooler under load, despite having higher
> TDP (however P9700 is a lot cooler when idle, as expected).
>
> Still, I don't think it is possible it's actually being overclocked?
>
>
>
> --
> View this message in context: 
> http://freebsd.1045724.x6.nabble.com/Bogus-turbo-mode-with-Intel-R-Core-TM-2-Duo-CPU-P9700-2-80GHz-tp6147461.html
> Sent from the freebsd-stable mailing list archive at Nabble.com.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Odp: Re: Bogus turbo mode with Intel(R) Core(TM)2 Duo CPU P9700 (2.80GHz)

[Jakub Lach]

Thanks for reply!   If I've understood you correctly, that means the ACPI   
table somehow provides (lists) turbo mode for this CPU   even though it does 
not support it [1]? Is there a way to   check it's real speed under load? 
I'm guessing no.   [1] ark.intel.com  ark.intel.com

  
   
 
  Dnia 26 listopada 2016 05:40 Adrian Chadd 
 napisał(a):
 
 
   the acpi cpu frequency module just exposes the frequency lis 
given to 
 it by ACPI. If your ACPI table exposes the turbo boost frequency but 
 doesn't implement it on the backend, FreeBSD doesn't know. We just 
 obey what we're told. :) 
  
  
 -a 
  
  
 On 25 November 2016 at 20:16, Jakub Lach  wrote: 
 
 Hello, 
  
 Since I'm running this CPU, I've noticed there is additional 
 field in supported frequency (under heavy load)- 
  
 dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 
 dev.cpu.0.freq_levels: 2801/35000 2800/35000 2450/30625 2133/23888 
 1866/20902 1600/15000 1400/13125 1200/11250 1000/9375 800/12000 700/10500 
 600/9000 500/7500 400/6000 300/4500 200/3000 100/1500 
 dev.cpu.0.freq: 2801 
 dev.cpu.0.temperature: 67,0C 
  
 as far as I know, the +1 MHz mode is a turbo boost factory 
 overclock, however this CPU does not support it. Anybody knows 
 what's going on? 
  
 I've previously had T9400 (2.53 GHz), there was no such thing listed 
 and it was running slightly cooler under load, despite having higher 
 TDP (however P9700 is a lot cooler when idle, as expected). 
  
 Still, I don't think it is possible it's actually being overclocked? 
  
  
  
 -- 
 View this message in context:  freebsd.1045724.x6.nabble.com 
freebsd.1045724.x6.nabble.com 
 Sent from the freebsd-stable mailing list archive at Nabble.com. 
 __ 
  freebsd-stable@freebsd.org  mailing list 
 lists.freebsd.org lists.freebsd.org 
 To unsubscribe, send any mail to "freebsd-stable-unsubscribe@fr
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Pizza Mussarella de R$ 34, 90 por R$ 24, 90 Só Hoje! Black Friday! Morumbi e Região!

[Morumbi Master]

Problemas com a mensagem? visualize no navegador.  Só 
Hoje! Black Friday! Pizza de Mussarella de R$ 34,90 por R$ 24,90!   
   www.morumbimaster.com.brUnidade Morumbi: Avenida Giovanni 
Gronchi , 2099, Morumbi, São Paulo, SP.Telefone: (011) 3742-1933 - 
(011) 4117-0284 - What´s (011) 98193-1544 (011) 
95925-9420Aplicativo: 
https://play.google.com/store/apps/details?id=com.appswiz.morumbimaster&hl=pt_BR
  Cancele o
recebimento | Denunciar abuso

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"