Date: Wed, 6 Dec 2000 17:56:13 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: smp@FreeBSD.ORG Subject: Re: Mutex types. Message-ID: <Pine.BSF.4.21.0012061713150.5526-100000@besplex.bde.org> In-Reply-To: <3A2D3786.5E8CC39F@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <sys/mutex.h> and <machine/mutex.h>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012061713150.5526-100000>