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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
