Date: Wed, 04 Sep 2002 18:30:34 -0700 From: Peter Wemm <peter@wemm.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: John Baldwin <jhb@freebsd.org>, freebsd-alpha@freebsd.org Subject: Re: alpha performance on -current Message-ID: <20020905013034.1D4B42A88D@canning.wemm.org> In-Reply-To: <15734.29725.515274.183629@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote: > [non-null null syscall tests] We really need a null system call to test for these. How about __sysnull(2)? What lmbench is testing is syscall overhead *plus* several iterations of mutex gain/releases. Possibly with a couple of sysctl knobs to enable turning on of "typical" locking operations. eg: kern.sysnull.giant = gain/release giant, kern.sysnull.proc = gain/release proc lock etc. Then we can easily test the *actual* syscall overhead. > Is the locking overhead this bad on x86? It looks downright > embarrassing on alpha. Can anything be done about it? Are the > memory barriers in atomic_cmpset_acq_* really needed? They have the > look of belt & suspenders code.. The mutex primitives are one the first things that will get serious optimization attention in order to squeeze every last erg out of the kernel when the time is right. That probably means doing away with the debugging hooks, having a place for MD implementations, etc. There are no shortage of eyes available to do this work, but right now what we have works and we most desperately need to not add another possible source of problems. We still haven't figured out why ithread preemption blows up on the alpha kernel, for example. This really needs to be identified. Given that the mutex stuff has pretty much settled down now, I think we could get away with optional 'fast-as-possible' mutexes now. I know there was some pending preemption and priority propagation work in progress that (I think) affected the implementation and data structures, but I think that's been shelved for now due to ongoing conflicts with KSE. Personally, I'd ship 5.0-R with a kernel option MUTEX_NODEBUG or something like that that strips them down and uses the fast MD implementations if they are available. Naturally this would be mutually exclusive with INVARIANTS, WITNESS etc. Leaving out MUTEX_NODEBUG would revert to the 'safe' version (just without the invariatns assertions etc). I'd probably enable this in GENERIC even. But, this is something for the re's to decide, not me. I know John has pretty strong opinions here so I will not try to speak for him. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020905013034.1D4B42A88D>