Date: Mon, 3 Oct 2011 19:09:43 -0400 From: Andrew Duane <aduane@juniper.net> To: Jayachandran C. <jchandra@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, Alexander Motin <mav@freebsd.org>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: RE: svn commit: r225892 - head/sys/mips/mips Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB80CB1F9B2@EMBX01-WF.jnpr.net> In-Reply-To: <CA%2B7sy7Cin5-cHcP-8_qYGhpEnAN9gw6S5ekXYK6Q3X9FREQggA@mail.gmail.com> References: <CA%2B7sy7BiRvTB79H9=y%2BS4jQ=%2BboW1bcDJn%2BBULMmJU9KLLVJ5A@mail.gmail.com> <CAJ-VmokAsDpjJLt%2BVJ2gDGX%2BiMAwZvL2TPaaAD_LRm-Yyquxig@mail.gmail.com> <CA%2B7sy7D6h5a08Q6yNfX6xSqwabDLzE5GLu5aV3fCMYQKn_4AoQ@mail.gmail.com> <CAJ-Vmon32cVEVvC=3WJVmDkCUdyLWyec3sqU-ifzspVSPxedfg@mail.gmail.com> <CAJ-Vmomsq5PQzbCBmWob5juB9EqdcEoYV%2B9vwYjnJQYTo_%2B4kw@mail.gmail.com> <CAJ-Vmon_a_zLZmEGqwFaYaobjYFE2i1u2Viq3QD5dw4wpNNURA@mail.gmail.com> <CA%2B7sy7DFCMxo-2bJwBJcSEJf7ewG7Y=XwdgKXkhpRyDXQpvsYA@mail.gmail.com> <CAJ-VmokPFqS2oNWZ_mFSxy=0MXfgqtOcBHSQe%2BdYXvsLHAyGjQ@mail.gmail.com> <CAJ-VmomqmKPRHBCbt46_xXD0VoU47Q-vYWbAqCFaM635ZnOHWA@mail.gmail.com> <CAJ-VmomLbueaG3bmnT0WfeKaMSyXSNo80BWXqEe39z6x%2Bx8QoA@mail.gmail.com> <20111002110331.GF1511@deviant.kiev.zoral.com.ua> <CA%2B7sy7A%2Bq_N6Hr%2B3-tD=BJxmqtDgBeWF9HJCtopLF0RUz6hVyw@mail.gmail.com> <CA%2B7sy7Ax9SXSK1CyxuBNboktJxuQTMiu3D4NFmZSoq7-ipoQgA@mail.gmail.com> <CA%2B7sy7Cin5-cHcP-8_qYGhpEnAN9gw6S5ekXYK6Q3X9FREQggA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The COP0_SYNC's should be there (should there also be one after the MTC0 in= MipsKernIntr?). The ISA says a hazard is needed, so that should be reflect= ed. I assume different platforms define COP0_SYNC for themselves as needed? Other comment: rather than adding 16 to the StartSkipWait address if skippi= ng over it, should the address of EndSkipWait be loaded instead? I can see = some real problems someday when the skip stuff goes past 16 bytes. =A0................................... Andrew Duane Juniper Networks o=A0=A0=A0+1 978 589 0551 m=A0 +1 603-770-7088 aduane@juniper.net =A0 > -----Original Message----- > From: owner-freebsd-mips@freebsd.org [mailto:owner-freebsd- > mips@freebsd.org] On Behalf Of Jayachandran C. > Sent: Monday, October 03, 2011 2:53 PM > To: Adrian Chadd > Cc: Kostik Belousov; Alexander Motin; freebsd-mips@freebsd.org > Subject: Re: svn commit: r225892 - head/sys/mips/mips >=20 > On Tue, Oct 4, 2011 at 12:34 AM, Jayachandran C. <jchandra@freebsd.org> > wrote: > > On Mon, Oct 3, 2011 at 10:19 PM, Jayachandran C. > <jchandra@freebsd.org> wrote: > >> Hi Adrain, > >> > >> On Sun, Oct 2, 2011 at 4:33 PM, Kostik Belousov > <kostikbel@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 =A0 =A0t1, 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.... >=20 > This version should be better(thanks to Juli for suggestions). Can you > see if this helps? >=20 > Thanks, > JC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC6674AB7BC78549BB231821ABF7A9AEB80CB1F9B2>