Re: MIPS PREEMPT_RT update..

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* john cooper <[email protected]> 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

--
[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]
  Powered by Linux