From owner-freebsd-smp Fri Dec 8 13:32:11 2000 From owner-freebsd-smp@FreeBSD.ORG Fri Dec 8 13:32:08 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id DFD0037B400; Fri, 8 Dec 2000 13:32:07 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id OAA15945; Fri, 8 Dec 2000 14:28:41 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAAlqaahF; Fri Dec 8 14:28:36 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id OAA23873; Fri, 8 Dec 2000 14:31:59 -0700 (MST) From: Terry Lambert Message-Id: <200012082131.OAA23873@usr01.primenet.com> Subject: Re: Netgraph and SMP To: cp@bsdi.com (Chuck Paterson) Date: Fri, 8 Dec 2000 21:31:59 +0000 (GMT) Cc: msmith@FreeBSD.ORG (Mike Smith), smp@FreeBSD.ORG In-Reply-To: <200012082121.eB8LLSQ07456@berserker.bsdi.com> from "Chuck Paterson" at Dec 08, 2000 02:21:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr01.primenet.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > For uses such as barriers for loading and unloading it is > possible to have the counters and entry barriers all PCPU. You can then > use more complex mechanisms to set the low level barrier and interrogate > the counters. Terry ->>may<<- view this as another way of doing > what he is suggesting. Yes. Specifically, it is not necessary to hold a mutex, only a spinlock, for the count adjust; you need only verify that the count is > 1, and the mutex is _not_ held. The negative logic saves you from the invalidation cycle on the shared resource (the mutex). The mutex need only be held when the driver is to be unloaded, or during loading, after wiring in, but prior to initialization. When doing this, you acquire the mutex before incrementing the hold count. For a non-zero hold count, you spin until it is zero, and deal with the unload. This means that the hold count and the mutex have to be associated with the slot for the driver, and not part of the loaded/unloaded data area, but it's well worth the effort. The other strategies having to do with caching are just gravy, in that they reduce the interprocessor contention considerably. You can go even further by locking interupts to cards, but that isn't necesary to get ~80% of the available win, anyway. This approach should be light enough to satisfy Julian, as well. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message