Date: Thu, 08 Mar 2001 23:34:51 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: alpha@FreeBSD.org Subject: RE: cvs commit: src/sys/alpha/include mutex.h src/sys/i386/inclu Message-ID: <XFMail.010308233451.jhb@FreeBSD.org> In-Reply-To: <200103090724.f297OIk50706@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010308233451.jhb>