* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
@ 2007-01-24 18:52 ` joshua dot i dot stone at intel dot com
2007-01-24 19:13 ` joshua dot i dot stone at intel dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: joshua dot i dot stone at intel dot com @ 2007-01-24 18:52 UTC (permalink / raw)
To: systemtap
------- Additional Comments From joshua dot i dot stone at intel dot com 2007-01-24 18:52 -------
If I may link to the relevant threads...
The first report was here:
http://sourceware.org/ml/systemtap/2007-q1/msg00174.html
My reply tries to explain *why* the current implementation has this deficiency:
http://sourceware.org/ml/systemtap/2007-q1/msg00175.html
These further replies seem to confirm my hunch that the resync with kernel time
is causing the negative intervals, as the resync happens in a timer callback
(i.e. during softirq-timer).
http://sourceware.org/ml/systemtap/2007-q1/msg00183.html
http://sourceware.org/ml/systemtap/2007-q1/msg00184.html
Possible solutions:
* Find a better estimate of the cpu freq
* Use a clock that's independent of cpu freq (e.g., a motherboard/chipset timer)
* Get the kernel to provide a lockless gettimeofday
* Others?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
2007-01-24 18:52 ` [Bug runtime/3916] " joshua dot i dot stone at intel dot com
@ 2007-01-24 19:13 ` joshua dot i dot stone at intel dot com
2007-01-24 19:32 ` fche at redhat dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: joshua dot i dot stone at intel dot com @ 2007-01-24 19:13 UTC (permalink / raw)
To: systemtap
------- Additional Comments From joshua dot i dot stone at intel dot com 2007-01-24 19:13 -------
Also worth reading is one of our own design documents, which was since removed
from CVS:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/src/tapsets/timestamp/Attic/timestamp_tapset.txt?rev=1.1&content-type=text/plain&cvsroot=systemtap
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
2007-01-24 18:52 ` [Bug runtime/3916] " joshua dot i dot stone at intel dot com
2007-01-24 19:13 ` joshua dot i dot stone at intel dot com
@ 2007-01-24 19:32 ` fche at redhat dot com
2007-06-07 2:15 ` joshua dot i dot stone at intel dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fche at redhat dot com @ 2007-01-24 19:32 UTC (permalink / raw)
To: systemtap
------- Additional Comments From fche at redhat dot com 2007-01-24 19:32 -------
(In reply to comment #1)
> Possible solutions:
> * Find a better estimate of the cpu freq
> * Use a clock that's independent of cpu freq (e.g., a motherboard/chipset timer)
> * Get the kernel to provide a lockless gettimeofday
> * Others?
One simple thing is to keep the per-cpu counts from ever decreasing during
the resynchronization phase. This could let them drift ahead of real time,
but so be it. If it gets too bad, the runtime could emit a warning.
Also, the resync phase may not be necessary so frequently on stable_tsc
processors.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
` (2 preceding siblings ...)
2007-01-24 19:32 ` fche at redhat dot com
@ 2007-06-07 2:15 ` joshua dot i dot stone at intel dot com
2007-08-15 9:10 ` mhiramat at redhat dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: joshua dot i dot stone at intel dot com @ 2007-06-07 2:15 UTC (permalink / raw)
To: systemtap
------- Additional Comments From joshua dot i dot stone at intel dot com 2007-06-07 02:15 -------
It seems that I like links. Here's another relevant mailing-list discussion:
http://sourceware.org/ml/systemtap/2007-q2/msg00505.html
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
` (3 preceding siblings ...)
2007-06-07 2:15 ` joshua dot i dot stone at intel dot com
@ 2007-08-15 9:10 ` mhiramat at redhat dot com
2007-08-15 15:11 ` mhiramat at redhat dot com
2007-08-16 18:17 ` joshua dot i dot stone at intel dot com
6 siblings, 0 replies; 8+ messages in thread
From: mhiramat at redhat dot com @ 2007-08-15 9:10 UTC (permalink / raw)
To: systemtap
------- Additional Comments From mhiramat at redhat dot com 2007-08-14 22:49 -------
(In reply to comment #4)
> It seems that I like links. Here's another relevant mailing-list discussion:
> http://sourceware.org/ml/systemtap/2007-q2/msg00505.html
I updated my patch.
However, I think this still needs to be discussed (especially,
about Core/Core2 architecture and newer AMD processors).
Thank you,
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
` (4 preceding siblings ...)
2007-08-15 9:10 ` mhiramat at redhat dot com
@ 2007-08-15 15:11 ` mhiramat at redhat dot com
2007-08-16 18:17 ` joshua dot i dot stone at intel dot com
6 siblings, 0 replies; 8+ messages in thread
From: mhiramat at redhat dot com @ 2007-08-15 15:11 UTC (permalink / raw)
To: systemtap
------- Additional Comments From mhiramat at redhat dot com 2007-08-14 22:51 -------
Created an attachment (id=1968)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=1968&action=view)
Initialize cpu_freq by using kernel variables
This patch changes systemtap's timer initialization
to use kernel variable instead of estimating it.
Masami
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug runtime/3916] improve timing monotony
2007-01-24 16:10 [Bug runtime/3916] New: improve timing monotony fche at redhat dot com
` (5 preceding siblings ...)
2007-08-15 15:11 ` mhiramat at redhat dot com
@ 2007-08-16 18:17 ` joshua dot i dot stone at intel dot com
6 siblings, 0 replies; 8+ messages in thread
From: joshua dot i dot stone at intel dot com @ 2007-08-16 18:17 UTC (permalink / raw)
To: systemtap
------- Additional Comments From joshua dot i dot stone at intel dot com 2007-08-16 16:17 -------
(In reply to comment #5)
> However, I think this still needs to be discussed (especially,
> about Core/Core2 architecture and newer AMD processors).
There is a synthesized cpu feature flag X86_FEATURE_CONSTANT_TSC, added in
2.6.13 for x86_64 and 2.6.16 for i386. Further, in 2.6.18 there's a tsc_khz
variable as a companion to the cpu_khz, and a check_tsc_unstable().
So hopefully we can make use of these features, though we'll need to gate it
with autoconf to continue supporting older kernels.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3916
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 8+ messages in thread