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

[Abbas Raza]

On 07/25/2011 08:19 PM, Mathieu Desnoyers wrote:
> * Abbas Raza (abbas_raza at mentor.com) wrote:
>> On 07/19/2011 08:18 PM, Mathieu Desnoyers wrote:
>>> * Abbas Raza (abbas_raza at mentor.com) wrote:
>>>> On 07/15/2011 12:05 PM, Abbas Raza wrote:
>>>>> Hello guys,
>>>>>
>>>>> There is a patch "trace-clock-userspace.patch" (available on 2.6.36)
>>>>> that syncs the clock so that both kernel and userspace trace sets are
>>>>> in perfect time sync. Currently this patch is only for x86
>>>>> architecture.
>>>>> Any idea or info that when this patch will be available for
>>>>> ARM/PowerPc architectures? Is this expected in next lttng patch
>>>>> releases?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Regards,
>>>>>
>>>>> Abbas Raza
>>>>>
>>>> Or can anyone give me some direction how to extend clock_gettime vdso to
>>>> read lttng trace clock from userspace for other architectures ARM/PowePc
>>>> ?
>>> Hi Abbas,
>>>
>>> The LTTng development is currently done on LTTng pre-2.0, in preparation
>>> for the upcoming 2.0 release. There is no plan to add features to the
>>> LTTng 0.x versions anymore (it is only in bugfix maintainance mode).
>>>
>>> As far as trace clocks are concerned, LTTng 2.0 currently uses the Linux
>>> kernel time source (temporary fallback, which is slower than lttng trace
>>> clocks, less precise and not nmi-reentrant). The plan is to merge the
>>> LTTng 0.x trace clocks into the LTTng 2.0 kernel modules
>>> (lttng-modules.git tree) and present them to userspace through a custom
>>> vDSO (a shared memory page allocated from a lttng-specific ioctl on the
>>> debugfs "lttng" file). The same page can be shared across all processes
>>> calling this ioctl. Its main purpose is to expose information from the
>>> kernel to userspace: typically a sequence lock and some data structure
>>> (either global and/or per-cpu) to show how e.g. to extend a 31-bit cycle
>>> counter to a 64-bit value, how to scale the cycle counter value to a
>>> reference frequency, etc.
>>>
>>> So if you want to help out, a first step would be to get the latest
>>> lttng 0.x trace clock code for all architectures and integrate it into
>>> lttng-modules.git master branch. Then, after this, we can focus on
>>> getting the vDSO to work.
>>>
>>> I'm currently busy working on LTTng-UST 2.0 (the userspace tracer part),
>>> which should be ready by the end of the summer. LTTng 2.0 kernel tracer
>>> works today, so we plan to do a pre-2.0 release soon (just for the
>>> kernel tracer and the lttng-tools control tools).
>>>
>>> Thanks!
>>>
>>> Mathieu
>>>
>>>> Thanks!
>>>>
>>>> _______________________________________________
>>>> ltt-dev mailing list
>>>> ltt-dev at lists.casi.polymtl.ca
>>>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>>>
>> Hello,
>>
>> Thanks a lot for reply !
>>
>> Just wanted to ask that which time source is used in LTTng 0.x for
>> kernel traces? As far as i know it uses trace clock which in turn use
>> TSC (in case of x86).
> LTTng 0.x uses its own "trace clock" implementation (which differs from
> the mainline trace clocks, and actually existed before those). In the
> case of x86, when the TSCs are synchronized across cores and CPUs, it
> uses the TSC as trace clock source. The rdtsc returns a 64-bit TSC
> value, which is what lttng needs.
>
>
>> Is it right? And thats the reason that since TSC is used for kernel
>> traces, so we must use the same for userspace traces to sync them up?
> Yes.
>
>> And for PowerPc instead of TSC, Time Base TB will be used?
> Yes. And on all powerpc flavors supported by LTTng, the TB register is
> synchronized across cores. The tb read high/low instructions allows
> reading a 64-bit TSC value, which is needed by LTTng.
>
>> Am i getting things right?
> Yes. On ARM however, the ccnt register is only 32-bit (and sometimes
> only 31 bits are usable due to overflow hardware issues). So it needs to
> be extended by software. Also, DVFS and power management can stop/start
> the counter and change its frequency. This is why we have to keep around
> data structures that allows finding back the current time based on an
> external reference (e.g. 32k clock). So in that care, we need to make
> both the ccnt register and these data structures visible in read-access
> from userspace in addition to the kernel, so userspace can read time
> without paying the performance penality of a round-trip to the kernel.
>
> I hope it makes things a little clearer,
>
> Mathieu
>
>> Thanks!
>>
>> Abbas Raza
>>
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>

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?

Thanks a lot again for help :)


Abbas Raza