svn commit: r225892 - head/sys/mips/mips

[Kostik Belousov]

On Sun, Oct 02, 2011 at 05:28:25PM +0800, Adrian Chadd wrote:
> Hi,
> 
> It doesn't look like openbsd or netbsd have tried addressing this.
> 
> I took a shot at trying to port over the relevant bits.
> 
> Linux seems to store the "can reschedule" flag in a bit of memory,
> rather than calling a function to check each time.
> This means that I can't simply port r4k_wait() verbose; there's no
> guarantee EPC would be pointing to inside r4k_wait if it had to call
> sched_runnable().
> 
> Also, since we are calling 'wait' inside a critical section, any EPC
> unwinding would have to also unwind the critical section (and maybe
> reprogram the timer) before restarting things. But since that now
> makes the "rollback" section even larger and unwieldy.
> 
> I really don't have the time or brain power at the moment to try and
> port this solution over from Linux.
> 
> I would really appreciate it if someone would help out here.

I probably need to describe some details of the mentioned "kib' idea".

Looking at the x86 sti; hlt sequence, I noted that, in fact, we do
not strictly need the special CPU behaviour of delaying enabling the
interrupts till next instruction after sti is executed. The race there
is the interrupt happen right after sti but before hlt, causing CPU
to enter halted state while potentially having runnable thread. On x86
it is closed by sti not enabling interrupts till hlt started execution
(it is more subtle, but let ignore the detail for the discussion).

Now, if sti would not offer the useful postponing behaviour, we can
easily emulate it. In the hardware interrupt handlers return path, we
can check for $pc being equal to the address of the hlt instruction. If
it is, we can advance $pc over the hlt, avoiding the halt if potentially
we have a runnable thread.

Briefly looking over the MIPS64 specifications, I do not see why we cannot
implement the spirit of the trick for the ei; wait instruction sequence.
ray talked about possibility of $pc living in the shadow register bank,
which I think is not important. Another (minor) issue seems to be
that our code does not use ei, directly manipulating the bit.

My belief is that the trick can be done if only we have exact
interrupts. It seems, from "run mips run" text, that possible inexact
interrupts are either for much older platforms then modern MIPS SoC, or
are irrelant there, because inexactness is only related to mul/div unit.

[I am not on mips@]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20111002/1b837b0e/attachment.pgp