Re: [Adeos-main] Re: [Xenomai-core] I-pipe latency tracer for ppc

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4213 bytes --]

Wolfgang Grandegger wrote:
> Philippe Gerum wrote:
>>
>> As promised, the I-pipe tracer has been ported to ppc. People working
>> on this architecture are invited to give it a try, it's a great tool
>> to find out where the cycles are actually going.
>>
>> Just apply the tracer patch on top of the Adeos patch bearing the same
>> revision number, and select the feature from the kernel configuration.
>> If you happen to have some issue while booting the instrumented kernel
>> on embedded setups (e.g. freeze after kernel decompression), try
>> reducing the size of the trace log (CONFIG_IPIPE_TRACE_SHIFT).
>>
>> http://download.gna.org/adeos/patches/v2.6/ppc/tracer/
> 
> I gave it a try on a rather low-end PowerPC Walnut board (AMCC PowerPC
> 405GP, Rev. E at 200 MHz, 16 kB I-Cache 8 kB D-Cache). A nice tool,
> indeed, and it works fine. I have attached the results from running the
> Xenomai latency "-t0" test with some load showing latencies up to 140
> us. The trace seems not to show any obvious problems, I think.
> 
> Thanks.
> 
> Wolfgang.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> bash-3.00# cat /proc/ipipe/version
> 1.3-00
> 
> bash-3.00# ./latency -p500
> == Sampling period: 500 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> ...
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTS|      59.020|      67.260|     138.910|       0|    00:54:31/00:54:31
> 
> bash-3.00# cat /proc/ipipe/trace/max
> I-pipe worst-case tracing service on 2.6.14/ipipe-1.3-00
> ------------------------------------------------------------
> Begin: 182095500 cycles, Trace Points: 192 (-10/+3), Length: 265 us
>  
>  +----- Hard IRQs ('|': locked)
>  |+---- <unused>
>  ||+--- <unused>
>  |||+-- Xenomai
>  ||||+- Linux ('*': domain stalled)
>  |||||                       +---------- Delay flag ('+': > 1 us, '!': > 10 us)
>  |||||                       |        +- NMI noise ('N')
>  |||||                       |        |
>       Type   User Val.   Time    Delay  Function (Parent)
>      *fn                  -30    3.465  timer_interrupt+0x14 (__ipipe_do_timer+0x30)
>      *fn                  -26    2.430  profile_tick+0x14 (timer_interrupt+0x130)
>      *fn                  -24    1.865  profile_hit+0x14 (profile_tick+0x78)
>      *fn                  -22    1.700  update_process_times+0x14 (timer_interrupt+0x13c)
>      *fn                  -20    3.505  account_system_time+0x14 (update_process_times+0xac)
>      *fn                  -17    2.195  update_mem_hiwater+0x14 (account_system_time+0x78)
>      *fn                  -15    1.200  run_local_timers+0x14 (update_process_times+0xb0)
>      *fn                  -14   11.905  raise_softirq+0x14 (run_local_timers+0x30)
>      *fn                   -2    1.200  __ipipe_restore_root+0x14 (raise_softirq+0x84)
>      *fn                   -1    1.095  __ipipe_stall_root+0x14 (__ipipe_restore_root+0x34)
>> |   *begin  0x80000000     0+   3.950  __ipipe_stall_root+0x98 (__ipipe_restore_root+0x34)
> :|   *fn                    3+   1.500  scheduler_tick+0x14 (update_process_times+0x7c)
> :|   *fn                    5+   4.040  sched_clock+0x14 (scheduler_tick+0x34)

This trace covers some long stall of the root domain, not the maximum
stall of the Xenomai domain that caused the 140 us above. See the
explanation for the stall bits above.

Maybe the maximum irq latency tracing is broken, I haven't tested it
with latest ipipe patch revision yet. Well, that max path should not
trigger on root-domain stalls as long as there is some higher priority
domain running - and it should have been reset on xenomai mounting. Hmm,
maybe only that reset does not work, please check by running "echo >
/proc/ipipe/trace/max" before the latency test.

You could also test if the -f option of latency works for you. You will
find the result of the back-trace freezing on max latency under
/proc/ipipe/trace/frozen. The number of back-trace points can be tuned
even after the event (only post-tracing required ahead-of-time tuning).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]