Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
...
Meanwhile I found a solution for the described unterminated trace (put
an explicite trace_end at the end of __ipipe_unstall_iret_root),
included the irq number in the begin/end report, and stumbled over some
other remaining
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
...
Meanwhile I found a solution for the described unterminated trace (put
an explicite trace_end at the end of __ipipe_unstall_iret_root),
included the irq number in the begin/end report, and stumbled over some
other remaining
Jan Kiszka wrote:
...
Meanwhile I found a solution for the described unterminated trace (put
an explicite trace_end at the end of __ipipe_unstall_iret_root),
included the irq number in the begin/end report, and stumbled over some
other remaining unterminated trace on a different machine. So,
Jan Kiszka wrote:
Hi again,
here comes the first update of the new latency tracer.
arch/i386/kernel/entry.S | 27 +++
arch/i386/kernel/ipipe-root.c |4
include/asm-i386/system.h | 70 +
include/linux/ipipe_trace.h |3
kernel/ipipe/Kconfig | 18 ++
Jan Kiszka wrote:
Hi again,
here comes the first update of the new latency tracer.
arch/i386/kernel/entry.S | 27 +++
Is there any good reason to patch the callers of __ipipe_handle_irq
instead of instrumenting the callee directly?
arch/i386/kernel/ipipe-root.c |4
