From owner-freebsd-alpha Fri Mar 9 10:57:31 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B52037B718; Fri, 9 Mar 2001 10:57:26 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA23071; Fri, 9 Mar 2001 10:57:28 -0800 Date: Fri, 9 Mar 2001 10:57:25 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: alpha@FreeBSD.ORG Subject: RE: cvs commit: src/sys/alpha/include mutex.h src/sys/i386/inclu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey! Sounds good! Now I feel better at looking at an UltraSparc port.... (as if!) > > On 09-Mar-01 John Baldwin wrote: > > jhb 2001/03/08 23:24:17 PST > > > > Modified files: > > sys/alpha/include mutex.h > > sys/i386/include mutex.h > > sys/ia64/include mutex.h > > sys/kern kern_mutex.c kern_fork.c > > sys/sys proc.h > > Log: > > Fix mtx_legal2block. The only time that it is bad to block on a mutex is > > if we hold a spin mutex, since we can trivially get into deadlocks if we > > start switching out of processes that hold spinlocks. Checking to see if > > interrupts were disabled was a sort of cheap way of doing this since most > > of the time interrupts were only disabled when holding a spin lock. At > > least on the i386. To fix this properly, use a per-process counter > > p_spinlocks that counts the number of spin locks currently held, and > > instead of checking to see if interrupts are disabled in the witness code, > > check to see if we hold any spin locks. Since child processes always > > start up with the sched lock magically held in fork_exit(), we initialize > > p_spinlocks to 1 for child processes. Note that proc0 doesn't go through > > fork_exit(), so it starts with no spin locks held. > > > > Consulting from: cp > > This is actually very good for the alpha, as the mtx_legal2block() that had > been in alpha/include/mutex.h was bogus. Also, with this out of the way, any > plans to disable interrupts via IPL for interrupt threads are now quite > feasible, as well as for any other architectures which don't allow us to disable > interrupts via PIC masks but only via the CPU. However, if we can selectively > disable interrupts on PICs or other controllers and allow other interrutps to > trigger while we continue to run in the kernel, we need to try and do that, as > it greatly improves interrupt latency. This will become more apparent when > Giant becomes more split up, as currently, almost all of the kernel effectively > blocks interrupts by virtue of holding Giant. > > So, yes, Matt, you were right in that counting on being able to disable > interrupts outside of the CPU is not valid, and it was not indeed part of the > original SMPng design, but was something I had read in to a cheesy > mtx_legal2block() that was valid on the i386. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message