Steven Rostedt wrote:
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.
It isn't an issue of getting a hook into the FUNCTION_PROLOGUE
(mcount() here) but rather of emulating the CALLER_ADDR[0123]
defs which map onto the gcc internal __builtin_return_address().
Doing so using the affectionately dubbed "Three Stooges Algorithm"
called out in the MIPS ABI is both complex and nondeterministic.
The entry FUNCTION_PROLOGUE hook provides a means to log the path
traveled thus far. __builtin_return_address() gives a way to
snapshot a stub of the stack invocation. Together they provide
somewhat complimentary but useful debug information.
We could log the stack invocation progress in the latency
instrumentation itself by noting a new invocation in the
FUNCTION_PROLOGUE and unwind of the same in the currently
unused FUNCTION_EPILOGUE hook. So we're just shadowing the
actual runtime stack in effect with a data structure which
can be traversed far more easily.
-john
--
[email protected]
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
