Re: MIPS PREEMPT_RT update..

[john cooper <john.cooper@timesys.com>]

Ingo Molnar wrote:
> * john cooper <john.cooper@timesys.com> wrote:
>
>
> > Ingo,
> >    Attached is a patch relative to 2.6.14-rc5-rt5
> > which brings arch/mips up to date for PREEMPT_RT.
> > This was derived from a similar patch I had for
> > 2.6.13 but I'd assumed it was rather dated to apply
> > to current work.  As it turned out both versions
> > were quite close.
>
>
> thanks - merged your patches, they will be in the next
> -rt release.

I neglected to mention the latency instrumentation
is a major TBD due to limitations of the MIPS ABI
which spill over into gcc.  Namely the gcc extension
__builtin_return_address(n) is not usable for 0 < n
(though I seem to recall it being broken for 0 as
well in gcc 3.4.1).

For ARM I was able to trivially walk the stack as
a substitute for __builtin_return_address().  Given
the involved and nondeterministic method of walking
the stack called out by the MIPS ABI I don't see
this as an option.  This limitation also appears to
have influenced arch/mips/kernel/traps.c: dump_stack(),
show_trace() as the ABI suggested method was abandoned.
Instead show_trace() simply scans through the entirety
of the stack, printing out anything and everything
which appears to be a valid kernel text address.  Your
stack trace is in there somewhere scattered amongst
a healthy assortment of unrelated data found in the
stack.

A potential solution may be some method of
maintaining a small circular buffer available per
thread of execution and overloading the mcount()
FUNCTION_PROLOGUE to log the entry address of the
function in which it is embedded.  However I don't
know if this is possible and even if so it doesn't
generalize well to asynchronous execution (interrupts,
exceptions) as there is no easy way to associate the
buffer context to the execution path.

Anyway this is on the back burner as I have a few
other issues to address beforehand.

-john

--
john.cooper@timesys.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/