Date: Thu, 05 Dec 1996 10:23:56 -0700 From: Steve Passe <smp@csn.net> To: Chris Csanady <ccsanady@friley216.res.iastate.edu> Cc: Peter Wemm <peter@spinner.dialix.com>, smp@freebsd.org Subject: Re: make locking more generic? Message-ID: <199612051723.KAA13519@clem.systemsix.com> In-Reply-To: Your message of "Thu, 05 Dec 1996 08:46:59 CST." <199612051447.IAA04684@friley216.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > ... >I wasn't referring to a fine grained implementation right off hand. Just >a couple more locks, and it would be quite difficult to get into a deadlock >situation with them. Even so, you could still call it giant locking.. :P another issue related to the current "giant lock" scheme is INT steering. The APICs use a 'Task Priority Register' and 'Process Priority Register' to determine which CPU gets IRQs from the IO APIC. Basically, the CPU running at the LOWEST priority gets sent any pending IRQs. The problem with the "giant lock" is that when a CPU holds it, no other CPU can service an INT since it spins on the lock. So whenever a CPU acquires the lock I have the code set the priority of that CPU to "VERY LOW". So now all pending INTs will be sent to it, which it can deal with since it already holds the lock. When a CPU releaes the lock it resets its priority to "NORMAL". The problem is that whenever a CPU gets an INT its PPR is increased to the priority of the INT, thus negating the "VERY LOW" prio I set in the TPR. So if a CPU is behind the lock because of an INT it WON'T get sent other pending INTs, the other CPU will. Now that we have IPIs working I hope to be able to send an IPI to the other CPUs telling them to set their TPR to "VERY HIGH", thus dis-abling them from getting INTs. After reading the last paragraph you might wonder why I even bother setting the CPU TPR to "VERY LOW", its because it is still beneficial for all other cases where the CPU holds the lock, syscalls, etc. In these cases the CPU PPR is not set by a pending INT and the TPR is the sole arbitor of the INT steerage. Anyways, the bottom line is that finer grain locking has to consider this INT streerage situation as well as the million other details involved! -- Steve Passe | powered by smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612051723.KAA13519>