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

[Jayachandran C.]

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

JC.