This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug runtime/16603] New: time loss-of-synchrony on fluctuating-cpufreq unsynchronized-tsc boxes


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]