Newbie question about profiling.

Newbie question about profiling.

[Lars Segerlund]

 Hello,

 I am fairly new to RT Preempt, but now to realtime embedded systems.
I am trying to get EMC2 running on RT Preempt, and I was given some
old patches on the mailing list which miracously worked.

 From here I am trying to get a complete system built from scratch
with 'latest' RT Preempt and EMC2.

 My question is how to go about finding out what causes latencies and
jitter, I have no problem to create some code to benchmark latencies
or jitter, but how do I find out where the kernel is spending it's
time ?

 Any hints would be much appreciated, since i really don't have a clue
on how to go about this.

 I was thinking that if I could create a realtime task to test for a
specific thing, I really would like a log of what the kernal was doing
right before this.
 The only way I can think of is creating a module with a ring buffer (
spill over ), and tracing the scheduler or interrupt handler .... ( by
hackíng some code to specifically do this ), this would only add a
small overhead AFAIK.

 Any idea's anyone ? or hints ?

 It seem's like just the thing that already might have a solution in
place, so I figured I should not reinvent the wheel.

 / best regards, Lars Segerlund.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Newbie question about profiling.

[Pradyumna Sampath]

Hi Lars,

On Thu, Sep 23, 2010 at 4:42 PM, Lars Segerlund
<lars.segerlund@gmail.com> wrote:

>  I was thinking that if I could create a realtime task to test for a
> specific thing, I really would like a log of what the kernal was doing
> right before this.
>  The only way I can think of is creating a module with a ring buffer (
> spill over ), and tracing the scheduler or interrupt handler .... ( by
> hackíng some code to specifically do this ), this would only add a
> small overhead AFAIK.
>
>  Any idea's anyone ? or hints ?
>
>  It seem's like just the thing that already might have a solution in
> place, so I figured I should not reinvent the wheel.

Yeah in the last couple of years a lot of tools have been developed to
do exaclty this kind of thing. You could look for ..

- FTrace https://rt.wiki.kernel.org/index.php/Ftrace
- Tuna
- LTTng
..

Im sure there are a couple more but Ive used ftrace and LTTng and they
are pretty cool.

best regards
/prady

-- 
http://www.prady.in
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Newbie question about profiling.

[gowrishankar]

On Thursday 23 September 2010 08:12 PM, Lars Segerlund wrote:
>   Hello,
>
>   I am fairly new to RT Preempt, but now to realtime embedded systems.
> I am trying to get EMC2 running on RT Preempt, and I was given some
> old patches on the mailing list which miracously worked.
>
>   From here I am trying to get a complete system built from scratch
> with 'latest' RT Preempt and EMC2.
>
>   My question is how to go about finding out what causes latencies and
> jitter, I have no problem to create some code to benchmark latencies
> or jitter, but how do I find out where the kernel is spending it's
> time ?
>
>    
Hi,
You can start with RT functional testcases which are already available
in LTP (https://rt.wiki.kernel.org/index.php/LTP%28Realtime_Test_Tree%29)

If you find tests failing for some reason, then it can be good place to 
start
investigating with the help of kernel inbuilt tracing tool (ftrace) where
you have options to trace particular subsystem (irqoff, preemptoff, 
wakeup..)
Check kernel Documentation/trace/ftrace.txt.

Thanks,
Gowrishankar
>   Any hints would be much appreciated, since i really don't have a clue
> on how to go about this.
>
>   I was thinking that if I could create a realtime task to test for a
> specific thing, I really would like a log of what the kernal was doing
> right before this.
>   The only way I can think of is creating a module with a ring buffer (
> spill over ), and tracing the scheduler or interrupt handler .... ( by
> hackíng some code to specifically do this ), this would only add a
> small overhead AFAIK.
>
>   Any idea's anyone ? or hints ?
>
>   It seem's like just the thing that already might have a solution in
> place, so I figured I should not reinvent the wheel.
>
>   / best regards, Lars Segerlund.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>    

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html