Jan Kiszka wrote: > Hi all, > > after a long day of experimenting with a new tracer revision (will get > posted later), I'm looking now for some external wisdom. > > I changed the instrumentation for high-domain stall times such that I > now attach to local_irq_disable_hw & friends instead. In case the > hard-IRQ status doesn't change, only a ipipe_trace_special is issued, a > trace_begin/end otherwise. Additionally, I grab the entering and exiting > of __ipipe_handle_irq and suppress two IRQ on/off points in > arch/i386/kernel/ipipe-root.c. See attached patch (will likely become > part of the tracer).
I failed to include the changes of entry.S, see the full patch posted in the related thread. > > Ok, this works significantly better than the previous approach. I just > tormented an Athlon 800 MHz box with Xenomai 2.1 revision 357 (old ipipe > IRQ layer) about 50 minutes with > > latency -p1000 -t1 > dd if=/dev/hda of=/dev/null > ping -f -s 1400 [from external] > cachebench [part of llcbench] > > The result was a maximum latency of 38 us (in-kernel periodic task) and > some traces which correlate quite well. I attached two of them, showing > the similarity between the final and last but one outputs of > /proc/ipipe/trace/max. Note that the instrumentation and the trace > recording add some overhead, how much is just going to be measured. > Result: 33 us without the tracer but otherwise identical boundary conditions. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
