From owner-freebsd-smp Thu Dec 5 11:43:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA27594 for smp-outgoing; Thu, 5 Dec 1996 11:43:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA27588 for ; Thu, 5 Dec 1996 11:43:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id MAA14434; Thu, 5 Dec 1996 12:40:56 -0700 Message-Id: <199612051940.MAA14434@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terry Lambert cc: ccsanady@friley216.res.iastate.edu, peter@spinner.dialix.com, smp@freebsd.org Subject: Re: make locking more generic? In-reply-to: Your message of "Thu, 05 Dec 1996 11:37:58 MST." <199612051837.LAA19621@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Dec 1996 12:40:55 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >> 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. > >I don't understand. > >If CPU 1 is servicing INT 12 from a disk controller, and you get INT 4 >from a serial port, don't you *want* CPU 2 to service the INT 4 in >parallel??? yes, you do. but the problem is that CPU 1 holds the lock, so if CPU2 tries to service INT 4, it starts spinning in the un-obtainable lock till CPU1 finishes servicing INT 12. At this point CPU1 releases the lock, CPU2 finally gets it and can proceed to service INT 4. Might as well let CPU2 alone to do whatever it is doing instead. If the INT 4 is of higher priority than INT 12, CPU1 could start servicing it immediatly. The proper form of fine-grainularity could eliminate this problem. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK-----