From owner-freebsd-mips@FreeBSD.ORG Mon Oct 3 23:11:16 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F9F7106566B; Mon, 3 Oct 2011 23:11:16 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA738FC13; Mon, 3 Oct 2011 23:11:14 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Oct 2011 16:11:15 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 3 Oct 2011 16:09:45 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 3 Oct 2011 19:09:44 -0400 From: Andrew Duane To: Jayachandran C. , Adrian Chadd Date: Mon, 3 Oct 2011 19:09:43 -0400 Thread-Topic: svn commit: r225892 - head/sys/mips/mips Thread-Index: AcyCFu3g86Fvn2RUTp+9INCwkE5EAQACjO0Q Message-ID: References: <20111002110331.GF1511@deviant.kiev.zoral.com.ua> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kostik Belousov , Alexander Motin , "freebsd-mips@freebsd.org" Subject: RE: svn commit: r225892 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 23:11:16 -0000 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. > wrote: > > On Mon, Oct 3, 2011 at 10:19 PM, Jayachandran C. > wrote: > >> Hi Adrain, > >> > >> On Sun, Oct 2, 2011 at 4:33 PM, Kostik Belousov > 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