Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Adding trace events into the kernel : (4 Items)
   
Adding trace events into the kernel  
I like to get a more detailed System Profiling information about the time spend in the kernel. What’s the best approach
 to add some time stamps for example.

A TraceEvent() call of type user event doesn’t work.
Re: Adding trace events into the kernel  
Hi Soenke,

Can you elaborate a bit on what you are trying to do, and what you have already tried?

Cheers,

Colin

Soenke Nielsen wrote:
> I like to get a more detailed System Profiling information about the 
> time spend in the kernel. What’s the best approach to add some time 
> stamps for example.
> 
> A TraceEvent() call of type user event doesn’t work.
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post4615
> 

-- 
cburgess@qnx.com
Re: Adding trace events into the kernel  
I've noticed bad message passing performance with certain messages sizes on a MPC8313. 1k messages arer slower than 2k 
messages.

I've captured this in a kev file. But I just see that going from "Send message" state to "Reply blocked" takes 37 usec 
in the 1k case and < 10usec for 2k messages. See attachment.

I'm wondering, if I can dig more deaply into the problem by adding trace stamps into the kernel.

Sönke
Attachment: Image SystemProfiler.JPG 145.89 KB
Re: Adding trace events into the kernel  
On Jan 29, 2008 6:16 AM, Sönke Nielsen <snielsen@qnx.com> wrote:

> I've noticed bad message passing performance with certain messages sizes
> on a MPC8313. 1k messages arer slower than 2k messages.
>
> I've captured this in a kev file. But I just see that going from "Send
> message" state to "Reply blocked" takes 37 usec in the 1k case and < 10usec
> for 2k messages. See attachment.
>
> I'm wondering, if I can dig more deaply into the problem by adding trace
> stamps into the kernel.
>
You could but you can't use TraceEvent() to do it ... it is a kernel call
and you are already in the kernel (assuming
you are instrumenting the message pass code), you would need to use the
internal trace_* calls in ker_trace or
nano_trace.

However, adding code into the message copy path will have a measurement
effect.  What I'd do first is to use
the trace to look at the overall scenario:
* Length of data/message
* State of receiver
* Length of READY queue's
.. etc

This will allow you to take a first look at the code and understand how the
code path differs in both scenarios
that you are tracing.

Thomas