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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to