From owner-freebsd-mips@FreeBSD.ORG Mon Oct 3 19:07:42 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 185D91065670; Mon, 3 Oct 2011 19:07:42 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD2728FC22; Mon, 3 Oct 2011 19:07:40 +0000 (UTC) Received: by wyj26 with SMTP id 26so4736272wyj.13 for ; Mon, 03 Oct 2011 12:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AVR3iclhTj97L9pVq9yHYj7RvbWwUXBcJiXVlA6Tk+U=; b=OP2MYi4R5M9r8FVpSAcyHe7yNRdqLy8PEmIEKv63RPutauMh8awDGjrTHsvmzib1RB /KjZhR2dlEiyXpOE7IVNsQ2dgyN1kdKIwq7JFfEodW23seZEODsWbyooO1R++tKvjtOf BmiDefJOKFCWlqyc9QMRm36uzXEayoiiZaBFs= MIME-Version: 1.0 Received: by 10.216.220.131 with SMTP id o3mr341301wep.11.1317668641271; Mon, 03 Oct 2011 12:04:01 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.29.78 with HTTP; Mon, 3 Oct 2011 12:04:01 -0700 (PDT) In-Reply-To: References: <20111002110331.GF1511@deviant.kiev.zoral.com.ua> Date: Tue, 4 Oct 2011 00:34:01 +0530 X-Google-Sender-Auth: IXXTnzzUHbw2fOfCC771zTy20Dg Message-ID: From: "Jayachandran C." To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 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 19:07:42 -0000 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 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.