From owner-freebsd-smp Mon Jul 14 13:02:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11124 for smp-outgoing; Mon, 14 Jul 1997 13:02:56 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11101; Mon, 14 Jul 1997 13:02:44 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id OAA00792; Mon, 14 Jul 1997 14:02:38 -0600 (MDT) Message-Id: <199707142002.OAA00792@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Luigi Rizzo cc: smp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: interrupt latency In-reply-to: Your message of "Mon, 14 Jul 1997 20:48:59 +0200." <199707141849.UAA11489@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 14:02:37 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I am not familiar at all with the SMP code or the apic, but using > a hardware solution seems extremely complex. Since you are looking > at solution to improve the int latency anyways, can you consider > the following approach: > > Replace the "giant lock" with a couple of nested locks; the most > external one would only allow the posting of the hardware intr to > some cpu, but not the acquisition of the "giant lock" (i.e. the > right to enter the kernel). The nested lock is what you currently > call 'the giant lock'. The APICs don't quite work that way. There is an IO APIC connected to the external INT sources, and a local APIC in each CPU. All the APICs communicate thru a private bus. The IO APIC sends the INT to whichever CPU it determines is the best candidate based on several algorithms. for more info on the APIC as currently used, see: http://www.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD