I have found a new source of weirdness with TSC using
clock_gettime(CLOCK_MONOTONIC_RAW,) :
The vsyscall_gtod_data.mult field changes somewhat between
calls to clock_gettime(CLOCK_MONOTONIC_RAW,),
so that sometimes an extra (2^24) nanoseconds are added or
removed from the value derived from
I have found a new source of weirdness with TSC using
clock_gettime(CLOCK_MONOTONIC_RAW,) :
The vsyscall_gtod_data.mult field changes somewhat between
calls to clock_gettime(CLOCK_MONOTONIC_RAW,),
so that sometimes an extra (2^24) nanoseconds are added or
removed from the value derived from
OK, last post on this issue today -
can anyone explain why, with standard 4.10.0 kernel & no new
'notsc_adjust' option, and the same maths being used, these two runs
should display
such a wide disparity between clock_gettime(CLOCK_MONOTONIC_RAW,)
values ? :
$ J/pub/ttsc/ttsc1
max_extended_leaf:
OK, last post on this issue today -
can anyone explain why, with standard 4.10.0 kernel & no new
'notsc_adjust' option, and the same maths being used, these two runs
should display
such a wide disparity between clock_gettime(CLOCK_MONOTONIC_RAW,)
values ? :
$ J/pub/ttsc/ttsc1
max_extended_leaf:
I actually tried adding a 'notsc_adjust' kernel option to disable any setting or
access to the TSC_ADJUST MSR, but then I see the problems - a big disparity
in values depending on which CPU the thread is scheduled - and no
improvement in clock_gettime() latency. So I don't think the new
I actually tried adding a 'notsc_adjust' kernel option to disable any setting or
access to the TSC_ADJUST MSR, but then I see the problems - a big disparity
in values depending on which CPU the thread is scheduled - and no
improvement in clock_gettime() latency. So I don't think the new
On Wed, 22 Feb 2017, Jason Vas Dias wrote:
> Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is
> read or written . It is probably because it genuinuely does not support
> any cpuid > 13 , or the modern TSC_ADJUST interface.
Err no. TSC_ADJUST is available when CPUID(70 EBX
On Wed, 22 Feb 2017, Jason Vas Dias wrote:
> Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is
> read or written . It is probably because it genuinuely does not support
> any cpuid > 13 , or the modern TSC_ADJUST interface.
Err no. TSC_ADJUST is available when CPUID(70 EBX
Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is
read or written . It is probably because it genuinuely does not
support any cpuid > 13 ,
or the modern TSC_ADJUST interface . This is probably why my clock_gettime()
latencies are so bad. Now I have to develop a patch to disable
Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is
read or written . It is probably because it genuinuely does not
support any cpuid > 13 ,
or the modern TSC_ADJUST interface . This is probably why my clock_gettime()
latencies are so bad. Now I have to develop a patch to disable
On 22/02/2017, Jason Vas Dias wrote:
> RE:
>>> 4.10 has new code which utilizes the TSC_ADJUST MSR.
>
> I just built an unpatched linux v4.10 with tglx's TSC improvements -
> much else improved in this kernel (like iwlwifi) - thanks!
>
> I have attached an updated
On 22/02/2017, Jason Vas Dias wrote:
> RE:
>>> 4.10 has new code which utilizes the TSC_ADJUST MSR.
>
> I just built an unpatched linux v4.10 with tglx's TSC improvements -
> much else improved in this kernel (like iwlwifi) - thanks!
>
> I have attached an updated version of the test program
RE:
>> 4.10 has new code which utilizes the TSC_ADJUST MSR.
I just built an unpatched linux v4.10 with tglx's TSC improvements -
much else improved in this kernel (like iwlwifi) - thanks!
I have attached an updated version of the test program which
doesn't print the bogus "Nominal TSC
RE:
>> 4.10 has new code which utilizes the TSC_ADJUST MSR.
I just built an unpatched linux v4.10 with tglx's TSC improvements -
much else improved in this kernel (like iwlwifi) - thanks!
I have attached an updated version of the test program which
doesn't print the bogus "Nominal TSC
Thank You for enlightening me -
I was just having a hard time believing that Intel would ship a chip
that features a monotonic, fixed frequency timestamp counter
without specifying in either documentation or on-chip or in ACPI what
precisely that hard-wired frequency is, but I now know that to
be
Thank You for enlightening me -
I was just having a hard time believing that Intel would ship a chip
that features a monotonic, fixed frequency timestamp counter
without specifying in either documentation or on-chip or in ACPI what
precisely that hard-wired frequency is, but I now know that to
be
On Sun, 19 Feb 2017, Jason Vas Dias wrote:
> CPUID:15H is available in user-space, returning the integers : ( 7,
> 832, 832 ) in EAX:EBX:ECX , yet boot_cpu_data.cpuid_level is 13 , so
> in detect_art() in tsc.c,
By some definition of available. You can feed CPUID random leaf numbers and
it will
On Sun, 19 Feb 2017, Jason Vas Dias wrote:
> CPUID:15H is available in user-space, returning the integers : ( 7,
> 832, 832 ) in EAX:EBX:ECX , yet boot_cpu_data.cpuid_level is 13 , so
> in detect_art() in tsc.c,
By some definition of available. You can feed CPUID random leaf numbers and
it will
Patch to make tsc.c set X86_FEATURE_ART and setup the TSC_ADJUST MSR
correctly on my "i7-4910MQ" CPU, which reports
( boot_cpu_data.cpuid_level==0x13 &&
boot_cpu_data.extended_cpuid_level==0x8008
), so the code didn't think it supported CPUID:15h, but it does .
Patch:
diff --git
Patch to make tsc.c set X86_FEATURE_ART and setup the TSC_ADJUST MSR
correctly on my "i7-4910MQ" CPU, which reports
( boot_cpu_data.cpuid_level==0x13 &&
boot_cpu_data.extended_cpuid_level==0x8008
), so the code didn't think it supported CPUID:15h, but it does .
Patch:
diff --git
I originally reported this issue on bugzilla.kernel.org : bug # 194609 :
https://bugzilla.kernel.org/show_bug.cgi?id=194609
, but it was not posted to the list .
My CPU reports 'model name' as
"Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz" ,
has 4 physical & 8 hyperthreading cores with a frequency
I originally reported this issue on bugzilla.kernel.org : bug # 194609 :
https://bugzilla.kernel.org/show_bug.cgi?id=194609
, but it was not posted to the list .
My CPU reports 'model name' as
"Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz" ,
has 4 physical & 8 hyperthreading cores with a frequency
22 matches
Mail list logo