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

[Jayachandran C.]

On Tue, Oct 4, 2011 at 12:34 AM, Jayachandran C. <jchandra at freebsd.org> wrote:
> On Mon, Oct 3, 2011 at 10:19 PM, Jayachandran C. <jchandra at freebsd.org> wrote:
>> 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...
>
> Actually there are two issues with this, the first is a simple bug, it
> should be :
> mtc0    t1, MIPS_COP_0_STATUS
>
> The second one is that a move to the status register should followed
> by a COP0 write hazard on some mips platforms (although not on
> XLR/XLP). Adding this hazard would make the calculations more
> complex....

This version should be better(thanks to Juli for suggestions).  Can
you see if this helps?

Thanks,
JC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mips_wait2.patch
Type: application/octet-stream
Size: 2237 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20111003/db231b79/mips_wait2.obj