Date: Fri, 8 Dec 2000 21:31:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cp@bsdi.com (Chuck Paterson) Cc: msmith@FreeBSD.ORG (Mike Smith), smp@FreeBSD.ORG Subject: Re: Netgraph and SMP Message-ID: <200012082131.OAA23873@usr01.primenet.com> In-Reply-To: <200012082121.eB8LLSQ07456@berserker.bsdi.com> from "Chuck Paterson" at Dec 08, 2000 02:21:28 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012082131.OAA23873>