From owner-freebsd-smp Thu Jul 6 10:55:36 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D5E237C033 for ; Thu, 6 Jul 2000 10:55:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA94534; Thu, 6 Jul 2000 10:43:23 -0700 (PDT) (envelope-from dillon) Date: Thu, 6 Jul 2000 10:43:23 -0700 (PDT) From: Matthew Dillon Message-Id: <200007061743.KAA94534@apollo.backplane.com> To: Doug Rabson Cc: Greg Lehey , Chuck Paterson , David Greenman , freebsd-smp@FreeBSD.ORG Subject: Re: SMP progress (was: Stepping on Toes) References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :A spin lock which is used from both top and bottom halves *must* disable :interrupts, surely. Since we will only really end up with approximately :one of these (sched_lock) I don't think there is a real problem. : :-- :Doug Rabson Mail: dfr@nlsystems.com Read the document I wrote a month ago that's sitting on apollo.backplane.com/FreeBSDSmp/ There are two ways to do this: (1) (The way I implemented it) For the schedular mutex, which is the only spin mutex in the system, interrupts are left enabled. If an interrupt occurs the interrupt vector code will test to see if the current cpu holds the schedular mutex. If it does, the code will set the appropriate ipending bit and return immediately. Pending interrupts are tested and run when the schedular mutex is released. Advantages: * Removes sti/cli from the critical mutex path, which is executed far more often then interrupts are. * Allows interrupts to be forwarded if we wanted to forward them, rather then blocking (at some point in the future) * Allows passive pickups of interrupts by idle processors (at some point in the future) * Allows us to implement a separate interrupt scheduler, if we want to (at some point in the future). * Allows us to implement a parallel spl mechanism (though apparently nobody is interested in doing that). Disadvantages: None. (2) (The way BSDI implemented it) When the schedular mutex is obtained interrupts are disabled, blocking interrupts from occuring. When the schedular mutex is released, interrupts are reenabled. An interrupt thus cannot occur while the schedular mutex is being held by the current process. Advantages: * Slightly less complex code. Disadvantages: * Does not allow any manipulation of pending interrupts to occur while the schedular lock is held. * Causes sti/cli to be run quite often, which slows down the critical path for spin mutexes. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message