From: phyomh@gmail.com (Sam Liao)
Subject: [ltt-dev] Problem on combine kernel trace and userspace trace.
Date: Wed, 3 Nov 2010 23:03:02 +0800 [thread overview]
Message-ID: <AANLkTikuJ9DNRNKfw0dMoR50BpjPh57MNO93oZZ70nis@mail.gmail.com> (raw)
In-Reply-To: <4CD16BF3.9020901@polymtl.ca>
Hi Julien,
Thanks for your answer.
On Wed, Nov 3, 2010 at 10:04 PM, Julien Desfossez
<julien.desfossez at polymtl.ca> wrote:
> Hi Sam,
>
> Thanks for posting this, regarding the issue with time synchronization
> of the traces, we are actually working exactly on it right now.
> The main problem for now is that the events are recorded in cycles in
> the trace which means we need to know the TSC frequency to convert back
> in sec.nsec in LTTV. From UST we don't have a clear way to access this
> information, so we are now working on a new option in clock_gettime to
> use the LTTng trace clock infrastructure to make it easy to synchronise
> kernel and ust traces. I will post more details soon.
>
So using different clock sources brings this problem.
> Regarding the possibility of combining the userspace and kernelspace
> events for the same process I'm not sure exactly how it works, from what
> I can see the PID is 0 in UST traces so the traces cannot really be
> merged but I will let the people more familiar with UST answer this one.
>
I think that even there is no PID related information in the UST trace, if
the kernel trace's timestamp is consistent with the ust's, then we can get the
ust event's pid context from context switch("sched_change") related kernel
events after combining the kernel and ust trace.
Thanks,
-Sam
> Thanks,
>
> Julien
>
>
> On 10-11-03 05:24 AM, Sam Liao wrote:
>> Hi,
>>
>> I'm trying to combine the kernel trace and userspace trace, and it
>> seems that the
>> the userspace events can not be recognized to the right process with the kernel
>> events. I'm not sure if this is a problem of timestamp between kernel
>> and userspace.
>>
>> Here is the environment I'm using:
>> ----
>> Linux Trace Toolkit Visualizer 0.12.35-20082010
>> linux kernel 2.6.34.6
>> ust-0.4. ( I update the clock to use clock_gettime).
>> ----
>>
>> Is there anything I missed? Also I'm thinking about one problem, if
>> ust using clock_gettime to
>> get the nonseconds timestamp which is actually the timestamp that the user
>> application is doing the clock_gettime system call instead the
>> userspace event, how ust
>> deal with such difference and get this fixed when trace combination?
>>
>> Thanks,
>> -Sam
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
next prev parent reply other threads:[~2010-11-03 15:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-03 9:24 Sam Liao
2010-11-03 14:04 ` Julien Desfossez
2010-11-03 15:03 ` Sam Liao [this message]
2010-11-03 15:13 ` Mathieu Desnoyers
2010-11-04 6:22 ` Sam Liao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikuJ9DNRNKfw0dMoR50BpjPh57MNO93oZZ70nis@mail.gmail.com \
--to=phyomh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox