From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:24:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAE8816A4D1 for ; Fri, 14 Jan 2005 21:24:09 +0000 (GMT) Received: from mail15.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C03F43D31 for ; Fri, 14 Jan 2005 21:24:09 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28658 invoked from network); 14 Jan 2005 21:24:09 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 14 Jan 2005 21:24:09 -0000 Received: from [10.50.40.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0ELNxcK043527 for ; Fri, 14 Jan 2005 16:24:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: current@FreeBSD.org Date: Fri, 14 Jan 2005 16:24:34 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501141624.34752.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: [PATCH] Divorce critical sections from spin mutexes (round 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:24:10 -0000 Ok, in the process of updating my tree that held the earlier version of the critical section vs. spin mutexes patch I think I have found and fixed the bug that may have caused the lockups a few people reported. As such, I'd like folks to test the updated patch. Details and such of what the patch does: - spin locks and critical sections are divorced. Specifically, the sole purpose of a critical section is to keep the current thread from being preempted until it exits the section. Nothing requires that the critical section actually disable interrupts during the section as any interrupt threads scheduled would simply not preempt either because they would be picked up by another CPU or preempt the current thread when it exited the critical section. However, spin locks do need to prevent themselves from being interrupted by any code that can try to acquire a spin lock. Strictly speaking, only spin mutexes used in interrupt context (sched_lock, icu_lock, locks in INTR_FAST handlers, sleepq locks, etc.) need to block interrupts, but if you have a mutex that is only used in top half code, you should probably be using a normal mutex anyway, so the set of spin mutexes not used in interrupt context tends to be small to empty. So far in SMPng, almost all critical sections have been inside of spin mutexes (since spin mutexes also need to block preemptions in addition to interrupts). Thus, for the sake of simplicity, critical sections also included the interrupt blocking behavior. (Keep in mind that this was an evolutionary process. :) However, as SMPng progresses, it has now become useful to divorce the two concepts, especially as some folks are working on locking schemes which just use critical sections to protect per-CPU resources that are not accessed from interrupt context. What this change does is to move the interrupt blocking/deferment/whatever bits that spin mutexes need into a separate spinlock_enter()/spinlock_exit() API completely implemented in MD code. critical sections, on the other hand, are now reduced to a simple per-thread nesting count and are now completely MI. - The MI code that creates idle threads for each of the CPUs no longer tries to set curthread up for the APs and no longer messes with the critnest count for the idlethreads. Instead, the MD code now explicitly borrows the idlethread context for the APs when it needs it and is responsible for adjusting the critical section and spinlock nesting counts to account for the weirdness of borrowing the context for the first context switch. I've tested this on SMP i386, SMP sparc64, and UP alpha. Testing on other archs and on SMP would be greatly appreciated. Patch is at http://www.FreeBSD.org/~jhb/patches/spinlock.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org