From owner-freebsd-smp Tue Dec 5 22:56:18 2000 From owner-freebsd-smp@FreeBSD.ORG Tue Dec 5 22:56:16 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9AD6437B401 for ; Tue, 5 Dec 2000 22:56:14 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id RAA15095; Wed, 6 Dec 2000 17:56:01 +1100 Date: Wed, 6 Dec 2000 17:56:13 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Julian Elischer Cc: smp@FreeBSD.ORG Subject: Re: Mutex types. In-Reply-To: <3A2D3786.5E8CC39F@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 5 Dec 2000, Julian Elischer wrote: > In my quest to try get netgraph SMP compatible, I've been diving into the > mutex code. Several things are noticiable. > > 1/ These aren't really very light weight. > There are cases when what is wanted is a spin-mudex that takes a couple of > instructions at most and is held for maybe 4 instructions. The mutexes > implemented in kern/kern_mutex.c > are very heavyweight, and not very suitable for fine-grain work. is there any > plan to introduce lighter contructs? From my perspective I KNOW I won't want to > recurse so I don't want all that recursion gumpf. The mutexes implemented in kern/kern_mutex.c are rarely called. Most of the implementation is in and , and most of the code there is normally optimized away after compile-time flags tests show that most of it is dead. That said, mutexes aren't _really_ _very_ light weight. The compile-time flags tests require inline functions or macros to work, and the inline code isn't very small. GENERIC grew by 100K text (5%) when (null, !SMP) simple locks were changed to mutexes. > 3/ The attempt to combine all types of mutexes into one has various side > effects. I dislike this too. > ... > were used in the compiler. I cannot believe that the attempt to make one > 'all-singing-and-dancing' mutex doesn't make the code and data bigger. The compile-time flags tests eliminate most of the code bloat (except without optimization of course). > 4/ I notice the comment in the man page: > ----- > This could result in deadlock if a thread interrupted > the thread which held a mutex and then tried to acquire the mutex; for > this reason spin locks will disable all interrupts (on the local CPU on- > ly) by default. > ----- > How expensive is it to disable all interrupts? Very expensive for latency. It makes interrupt latency on a 486DX2/66 worse than it used to be on a 386SX/16. (The 486DX2/66 was the slowest machine I could find to test on :-). It was just slow enough to demonstrate breakage of fast interrupt handling for sio.) I have unfinished fixes for this. (Essentially, upgrade to the old interrupt masking scheme again -- use the core of its internals for the same reasons as before, although not the driver interface (spl*())). This only works right on machines that have per-interrupt interrupt masking, but so does our general interrupt scheme.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message