On Sun, Oct 10, 2010 at 6:01 PM, Artyom Tarasenko <atar4q...@gmail.com> wrote: > On Sun, Oct 10, 2010 at 7:37 PM, Artyom Tarasenko <atar4q...@gmail.com> wrote: >> On Sat, Oct 9, 2010 at 5:10 PM, Blue Swirl <blauwir...@gmail.com> wrote: >>> Replace some debug printf statements with tracepoints. >>> >>> Signed-off-by: Blue Swirl <blauwir...@gmail.com> >>> --- >>> I think tracing way is more flexible than current conditional code. I >>> remember wading through hundreds of megs of DPRINTF output looking for >>> a clue about a specific event, so being able to control the trace >>> dynamically is invaluable. >>> >>> Here's example simpletrace.py output: >>> sparc64_translate 0.000 address=0x1fff0000040 paddr=0x1fff0000040 >>> vaddr=0x1fff0000000 mmu_idx=0x4 primary_context=0x0 >>> secondary_context=0x0 >>> sparc64_translate 24.017 address=0x1fff000bc50 paddr=0x1fff000bc50 >>> vaddr=0x1fff000a000 mmu_idx=0x4 primary_context=0x0 >>> secondary_context=0x0 >>> sparc64_translate 3.921 address=0x1fff000bc5c paddr=0x1fff000bc5c >>> vaddr=0x1fff000a000 mmu_idx=0x2 primary_context=0x0 >>> secondary_context=0x0 >>> sparc64_translate 337.702 address=0x1fff000bf38 paddr=0x1fff000bf38 >>> vaddr=0x1fff000a000 mmu_idx=0x2 primary_context=0x0 >>> secondary_context=0x0 >>> >>> There are problems #including "trace.h" from op_helper.c >>> (qemu-common.h conflicts with dyngen-exec.h), otherwise this looks >>> promising. >>> --- >>> target-sparc/helper.c | 65 >>> +++++++++++------------------------------------- >>> trace-events | 10 +++++++ >>> 2 files changed, 25 insertions(+), 50 deletions(-) >>> >>> diff --git a/target-sparc/helper.c b/target-sparc/helper.c >>> index aa1fd63..8078d92 100644 >>> --- a/target-sparc/helper.c >>> +++ b/target-sparc/helper.c >>> @@ -26,17 +26,11 @@ >>> #include "cpu.h" >>> #include "exec-all.h" >>> #include "qemu-common.h" >>> +#include "trace.h" >>> >>> //#define DEBUG_MMU >>> //#define DEBUG_FEATURES >>> >>> -#ifdef DEBUG_MMU >> >> wouldn't it be better to keep the #ifdefs? Don't mmu functions have a >> strong impact on the performance? > > After reading how the nop backed works, I take it back.
Even a full trace with all Sparc stuff enabled using simpletrace backend seems to have very low overhead compared to printfs. I suppose async I/O would lower the overhead even more.
