Hi Stephane,
I am a little confused now. I thought perfmon uses TSC to timestamp
samples. For example, the pfmon command:
$ pfmon --smpl-module=compact --with-header
-emy_event,unhalted_reference_cycles --long-smpl-periods=140000
my_program
gives:
# description of columns:
# column 1: entry number
# column 2: process id
# column 3: thread id
# column 4: cpu number
# column 5: instruction pointer
# column 6: unique timestamp
# column 7: overflowed PMD index
# column 8: event set
# column 9: initial value of overflowed PMD (sampling period)
# followed by optional sampled PMD values in command line order
#
#
0 5854 5854 3 0x400621 0x0000002aaadf4476 17 0
-140000 0x3363c
1 5854 5854 3 0x400621 0x0000002aaae0b512 17 0
-140000 0x66c78
2 5854 5854 3 0x400621 0x0000002aaae21813 17 0
-140000 0x9a2bd
3 5854 5854 3 0x400621 0x0000002aaae37a5c 17 0
-140000 0xcd8f9
4 5854 5854 3 0x400621 0x0000002aaae4dc69 17 0
-140000 0x100f3e
5 5854 5854 3 0x400621 0x0000002aaae63e67 17 0
-140000 0x134583
So, column #6 is the TSC value divided by the CPU freq (i.e. time from reset in
ns).
You mentioned a tstamp field in the sample that relies on sched_clock(). Is
that another timestamp field ? If yes, how can I display it using pfmon ?
thanks,
- nagy
stephane eranian wrote:
> Hello,
>
> On Wed, Jan 21, 2009 at 2:41 PM, Nagy Mostafa <[email protected]> wrote:
>
>> Hi,
>> I am trying to correlate timestamped samples by pfmon to timestamped events
>> collected from the profiled program by instrumentation. The samples and
>> events are collected from the same run. In other words, I run my
>> instrumented program using pfmon to collect a pfmon profile and a
>> timestamped execution trace. For pfmon I simply use the unique timestamp
>> column value (based on TSC) and I use rdtsc for my program. My problem is
>> that the timestamps do not match, there is always a shift that is large
>> enough to make the first pfmon sample out of range of the collected events.
>> I am using a dual core x86 machine. My questions are:
>>
>>
> I am assuming you are talking about the tstamp field in the sample. This one
> reports a unique timestamp based on the kernel sched_clock() interface. it is
> different from the TSC. If I recall correctly, it returns the current
> time in ns.
> If multiple cores call this function in the same nanosecond, they could get
> the
> same value, very unlikely though.
>
> As for your problem, I would not expect the timestamps to match exactly
> anyway.
>
>
>> - I am assuming this is because of frequency scaling effect. Could it be
>> something else ?
>>
>
> I think on recent Intel (and AMD) processor, the TSC is not affected by
> frequency scaling. This is a feature indicated by constant_tsc flag in
> /proc/cpuinfo.
> But I am not an x86 expert.
>
>
>> - If I turn off freq. scaling, is it guaranteed that TSC value will be
>> synchronized on both cores ?
>>
>
> No.
>
>
>> - I use rdtsc because it is the only way I know that enables me to read time
>> from user-space without a syscall, so it is cheap. Is there any better ways
>> of doing that for x86 or other architectures ?
>>
>>
> gettimeofday() has some fast implementations using lightweight
> syscalls if I recall.
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
