Date: Fri, 9 Mar 2001 10:57:25 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: alpha@FreeBSD.ORG Subject: RE: cvs commit: src/sys/alpha/include mutex.h src/sys/i386/inclu Message-ID: <Pine.LNX.4.21.0103091057000.21042-100000@zeppo.feral.com> In-Reply-To: <XFMail.010308233451.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0103091057000.21042-100000>