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

[Mathieu Desnoyers]

* 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
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com