This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/16603] New: time loss-of-synchrony on fluctuating-cpufreq unsynchronized-tsc boxes
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 18 Feb 2014 17:40:06 +0000
- Subject: [Bug runtime/16603] New: time loss-of-synchrony on fluctuating-cpufreq unsynchronized-tsc boxes
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16603
Bug ID: 16603
Summary: time loss-of-synchrony on fluctuating-cpufreq
unsynchronized-tsc boxes
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: runtime
Assignee: systemtap at sourceware dot org
Reporter: fche at redhat dot com
On some old boxes (AMD Athlon(tm) X2 Dual Core Processor BE-2300)
and perhaps NUMA ones, TSC values are not synchronized across cores,
and CPUFREQ changes give a good workout for the runtime/time.c code.
One assumption in the cpufreq notification callback has been found
to be invalid with modern kernels: that the notifier is itself
executed on the CPU whose frequency changed. If it isn't, we cannot
update together the then-correct base time/get_cycles pair. That
can lead to wild jumps or drifts of time.
global t
probe timer.profile { t[cpu()]=gettimeofday_s() }
probe timer.s(1) { foreach (c in t) printf("%d %s ", c, ctime(t[c]))
printf("\n") }
--
You are receiving this mail because:
You are the assignee for the bug.