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

[Jayachandran C.]

Hi Adrain,

On Sun, Oct 2, 2011 at 4:33 PM, Kostik Belousov <kostikbel at gmail.com> wrote:
> 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@]

I have implemented a variant of this, can you try out the attached
patch and see how it goes? It should apply on the version before your
changes to machdep.c

Also, if anybody on mips@ can review the code, it would be helpful...

JC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mips_wait.patch
Type: text/x-patch
Size: 2237 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20111003/8c337638/mips_wait.bin