Re: MIPS PREEMPT_RT update..

Re: MIPS PREEMPT_RT update..

[Ingo Molnar]

* 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.

	Ingo

Re: MIPS PREEMPT_RT update..

[john cooper]

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

Re: MIPS PREEMPT_RT update..

[Ingo Molnar]

* john cooper <john.cooper@timesys.com> wrote:

> As a qualification, I am still chasing a few problems which I suspect 
> are related to the Malta patch for 2.6.14 rather than the mips-rt 
> patch.  One appears to be a TLB handler problem in 2.6.14.  The other 
> appears to be potentially excessive context switching, although I 
> haven't had the opportunity yet to fully investigate this issue.  I 
> will follow up should resolution of these feed back into generic 
> mips-rt support.

FYI, i have released your big MIPS merge as part of 2.6.14-rt9. [please 
double-check i did not mis-merge any component]

wrt. your TLB problems: it might be related that TLB handling got 
simplified (and sped up) with the introduction of a generic, preemptible 
method to handle TLB-gathers. There's no tlb-simple.h anymore.

excessive context-switching might happen in some cases when we ping-pong 
short-held locks, and i'm certainly interested in a reproducer or 
analysis (or patch! :-).

	Ingo