[ltt-dev] trace-clock-userspace.patch for ARM/PowerPC ?

[Abbas Raza]

On 07/28/2011 10:26 PM, Mathieu Desnoyers wrote:
> * Abbas Raza (abbas_raza at mentor.com) wrote:
>> On 07/26/2011 11:02 PM, Mathieu Desnoyers wrote:
>>> * Abbas Raza (abbas_raza at mentor.com) wrote:
>>>> On 07/26/2011 10:17 PM, Mathieu Desnoyers wrote:
>>>>> * Abbas Raza (abbas_raza at mentor.com) wrote:
>>>>> [...]
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> Some confusion here :(
>>>>>>
>>>>>> In case of LTTng 0.x, when we take kernel traces then timestamps for
>>>>>> these traces is based on TSC/TB . So after that we view these traces by
>>>>>> lttv and it shows timestamps with all events which occurred.
>>>>>> I print the timestamp in kernel ltt function 'ltt_trace_alloc()'  and it
>>>>>> comes out to be 22944596907 (by calling trace_clock_read64() ). While
>>>>>> lttv show Birth sec of first event to 367 second. How this conversion is
>>>>>> made from TSC to the Birth sec/nsec value displayed in lttv? just want
>>>>>> to confirm that whether timestamps shown in lttv (Birth sec/nsec) are
>>>>>> based on TSC values... if yes then how TSC values are converted to Birth
>>>>>> sec/nsec and i no then from where lttv gets timestamps to be displayed?
>>>>>> Or in simple words, do kernel traces which we get contain timestamps
>>>>>> based simply on TSC values or it is something else?
>>>>> Yes, we write, in the lttng 0.x headers, the following information:
>>>>>
>>>>> struct ltt_subbuffer_header {
>>>>>     [...]
>>>>>            uint64_t start_freq;            /*
>>>>>                                             * Frequency at trace start,
>>>>>                                             * used all along the trace.
>>>>>                                             */
>>>>>            uint32_t freq_scale;            /* Frequency scaling (divisor) */
>>>>> [...]
>>>>> }
>>>>>
>>>>> so by using the start frequency and the scale, we can convert from TSC
>>>>> values to nanoseconds. Please note that LTTng 0.x requires the clock
>>>>> source to appear as if it has a constant rate.
>>>>>
>>>>> These values map to trace_clock_frequency() and trace_clock_freq_scale()
>>>>> trace clock functions.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Mathieu
>>>>>
>>>>>> Thanks a lot again for help :)
>>>>>>
>>>>>>
>>>>>> Abbas Raza
>>>>>>
>>>> Just to confirm that TSC's just have raw values of clock cycles and lttv
>>>> converts these values into sec/nsec by reading ltt_subbuffer_header ?
>>> Yes, that's it.
>>>
>>> Thanks,
>>>
>>> Mathieu
>>>
>>>> Thanks!
>>>>
>>>> Abbas Raza
>>>>
>> Hello Mathieu,
>>
>> Just wanted to ask that trace clock userspace patch for x86 adds
>> functionality to register posix clocks like
>>
>> register_posix_clock(CLOCK_TRACE,&clock_trace);
>> register_posix_clock(CLOCK_TRACE_FREQ,&clock_trace_freq);
>>
>> What we understood is that these clocks are registered to provide system
>> call functionality for CLOCK_TRACE and CLOCK_TRACE_FREQ clocks just like
>> other posix clocks. Right?
>>
>> And same we will have to do for powerpc (even if we have got vdso
>> functionality for these clocks)?
> Yes, exactly. The kernel always needs to provide a system call fallback
> for vDSO, just in case the vDSO cannot be used.
>
> Thanks
>
> Mathieu
>
>> Thanks !
>>
>> --
>> Abbas Raza
>>

Hello Mathieu,

We have added userspace trace clock support for powerpc architecture. We 
have verified our changes and userspace, kernel traces appear to be in 
sync for powerpc now. Patches are attached for kernel and UST.

Thanks!

Abbas Raza

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-use-of-TRACE_CLOCK_FREQ-UST-PPC.patch
Type: text/x-patch
Size: 1455 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110804/4f9f3ef8/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-TRACE_CLOCK-and-TRACE_CLOCK_FREQ-in-clock_gettime-PPC.patch
Type: text/x-patch
Size: 6147 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110804/4f9f3ef8/attachment-0007.bin>