Date: Tue, 29 Jun 1999 15:22:56 -0600 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: vanmaren@cs.utah.edu (Kevin Van maren), freebsd-smp@FreeBSD.ORG Subject: Re: high-efficiency SMP locks - submission for review Message-ID: <199906292122.PAA09761@mt.sri.com> In-Reply-To: <199906292115.OAA26919@usr08.primenet.com> References: <199906291705.LAA20627@zane.cs.utah.edu> <199906292115.OAA26919@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Just a quick summary (from my point of view): > > 1) Multi-threading the kernel will require locking, not just spl(). > > 2) Locking will likely slow down uni-processor systems. > > Locking in combination with multithreading should actually speed > up uniprocessor systems. > > The SVR4.2 (UnixWare 2.0) release was ~15% faster on UP, *with* > locking, due to the fact that a lot of th UP code benefitted > from deserialization of multiple simultaneous kernel operations. I'm in extreme doubt that any of this was due to locking, and was probably due to re-coding some of the less effecient algorithms and or better design. Re-design can cause this, but locking is *never* an optimization, just a necessary evil. Re-design your system to do a multi-threaded design, but the 'simple' solution of adding locking is in no way going to speed up the kernel. And, I don't see FreeBSD doing a completely new kernel design anytime in near future, that's what John Dyson's G2 kernel stuff is supposed to be. :) Nate 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?199906292122.PAA09761>