On 07/25/2011 08:19 PM, Mathieu Desnoyers wrote:
* Abbas Raza ([email protected]) wrote:
On 07/19/2011 08:18 PM, Mathieu Desnoyers wrote:
* Abbas Raza ([email protected]) 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
[email protected]
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
[email protected]
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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
