On Thu, 15 Nov 2007, Tim Bird wrote: > john cooper wrote: > > The more daunting problem stems from limitations in the MIPS > > ABI which makes the latency trace support problematic. > > Rather than rehash the issue: > > > > http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html > > > > Until we have a usable instrumentation solution in place, > > characterization, debug, and support of PREEMPT_RT for MIPS > > is going to be a challenge. > > Agreed. I have been using KFT (Kernel Function Trace) > on MIPS, and it has decent support for function traceback > reporting, but it's not currently integrated with latency-trace > at all. We should discuss if this could possibly be > used to debug RT-preempt. It is much heavier weight than > the mcount stuff, but uses similar (but not identical) > gcc profiling instrumentation. I'm not sure if the > two can be turned on together, or how hard it would > be to move latency-trace onto -finstrument_functions.
I'm not familiar with the KFT but I'm sure it would be easy to port latency_trace to it. Really, all the mcount does is make a wrapper to pass to the trace calls. Here's the code for mcount in arch/x86/kernel/entry_64.S: ENTRY(mcount) cmpl $0, mcount_enabled jz out push %rbp mov %rsp,%rbp push %r11 push %r10 push %r9 push %r8 push %rdi push %rsi push %rdx push %rcx push %rax mov 0x0(%rbp),%rax mov 0x8(%rbp),%rdi mov 0x8(%rax),%rsi call __trace pop %rax pop %rcx pop %rdx pop %rsi pop %rdi pop %r8 pop %r9 pop %r10 pop %r11 pop %rbp out: ret Which simply passes to __trace the rip that jumped here, and (if possible) the rip of that caller. The parent rip is not necessary. > > But it's probably worth researching a little. We'll > need something to give insight into the problem paths. If the KFT could do the above, it should be trivial to adapt. Hmm, if someone is willing to send me a free mips box, I may do it myself ;-) -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/