From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 09:54:11 2010 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 323FF1065692 for ; Tue, 26 Jan 2010 09:54:11 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id ECF9C8FC16 for ; Tue, 26 Jan 2010 09:54:10 +0000 (UTC) Received: by iwn42 with SMTP id 42so1423933iwn.9 for ; Tue, 26 Jan 2010 01:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=VxiYGSyyRuHWjNqch2q6NBUpisvO1Q0+kvYhWXBBQFA=; b=UtvQiAUysfcfWak/ybya0sxaURVDA8VcSTUWYeJr2dGPQ7FzgcZWN//ZC2TxHn88Le qQOIxphaDEGKTvqHZz73jssL6orj3u/XQOrVnD2AzhhkAm4b9Z1fbVSJFrDC1Gf5SNyt f7a2MSKztz/zGe3aA/1sKRuxstgfJiSbTAB2A= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=fQGmFRYNRnn9zoQUCLwoJAbbCCFk08gPWEm5NgJcRy/M5CigGw5bR24XRhAJHIp2Ob sn9aRwdTvy1AjRAG4tcePJZVD+eGtQeMXbi51xMRMboYTh8iNfZ1b91CuVZUeM9Gye8A 6d1B/Ng8hRXFtxCzfFQDjUAE3p5w5iisbSqWs= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.146.134 with SMTP id h6mr692569ibv.16.1264497847271; Tue, 26 Jan 2010 01:24:07 -0800 (PST) In-Reply-To: <489828.45501.qm@web34403.mail.mud.yahoo.com> References: <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net> <489828.45501.qm@web34403.mail.mud.yahoo.com> Date: Tue, 26 Jan 2010 10:24:07 +0100 X-Google-Sender-Auth: 28e5667ff36f5ac7 Message-ID: <3bbf2fe11001260124h423bd73ev38ba939d34155c54@mail.gmail.com> From: Attilio Rao To: Neelkanth Natu Content-Type: text/plain; charset=UTF-8 Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC 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: Tue, 26 Jan 2010 09:54:11 -0000 2010/1/25 Neelkanth Natu : > Hi Randall, > > --- On Mon, 1/25/10, Randall Stewart wrote: > >> From: Randall Stewart >> Subject: Re: AR71XX RTC >> To: "Neelkanth Natu" >> Cc: "M. Warner Losh" , freebsd-mips@freebsd.org >> Date: Monday, January 25, 2010, 12:51 PM >> Neil: >> >> Thanks for the patch.. it does look good since the old >> code was tromping part of the old threads PCB which is >> definitely not right ;-0 .. I do have a question for you.. >> forgive my ignorance.. >> >> What exactly are we trying to switch here. It seems >> that cpu_switch(...) is now being called with >> oldtd, newtd and mtx... >> >> I see that the thread structure has a struct mutex *td_lock >> as >> its first member. But what is this supposed to be pointing >> to? >> And when we switch are we trying to take the >> >> oldtd->td_lock and place it into the newtd->td_lock >> >> Or? >> >> What... I guess I just don't have any context for whats >> going on.. >> > > I am not very sure about this myself so take this with a grain of salt: > > When a thread is being switched out because it is on a sleep queue the > intent is that some other thread running on a different cpu should not be > allowed to muck with this thread's state. To make this happen the 'td_lock' > of 'oldtd' is switched from what it was originally (viz. the sleep queue > chain lock) to 'blocked_lock'. The 'blocked_lock' is special because > it is always locked. This all happens in sched_switch(). > > cpu_switch() is passed the original value of 'oldtd->td_lock' > as the third argument. When the context is switched to 'newtd' we will > switch back the 'oldtd->td_lock' from 'blocked_lock' to its original > value. And this way we don't lose any wakeups that may happen while we > are in sched_switch(). > > At least that is my very naive understanding of it. CCing Attilio to > shed more light on this. Hope this little explanation may give more guidance: http://lists.freebsd.org/pipermail/svn-src-head/2010-January/014038.html anyways, the interesting bits in, eg. i386 are: #if defined(SMP) && defined(SCHED_ULE) #define SETOP xchgl #define BLOCK_SPIN(reg) \ movl $blocked_lock,%eax ; \ 100: ; \ lock ; \ cmpxchgl %eax,TD_LOCK(reg) ; \ jne 101f ; \ pause ; \ jmp 100b ; \ 101: #else #define SETOP movl #define BLOCK_SPIN(reg) #endif The difference with SETOP is just for providing a rel memory barriers vs. not providing a rel memory barrier (thus be careful, if you want to support ULE, to follow the same logic), while BLOCK_SPIN() does: while (oldtd->td_lock == &blocked_lock) cpu_spinwait(); still enforcing an acq memory barrier on it. Then you may see when these functions are used, but that should be very MD specific. Attilio -- Peace can only be achieved by understanding - A. Einstein