Date: Thu, 21 Feb 2002 08:02:31 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Greg Lehey <grog@FreeBSD.ORG> Cc: John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG, "David O'Brien" <obrien@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com>, Jake Burkholder <jake@locore.ca> Subject: Re: Patch to improve mutex collision performance Message-ID: <Pine.GSO.4.10.10202210747440.22483-100000@pcnet1.pcnet.com> In-Reply-To: <20020221160212.H65817@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Feb 2002, Greg Lehey wrote: > On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: > > > >>> What John's patch does is spin while the lock owner is running on > >>> another cpu. Spinning while there are no other processes on the run > >>> queues as well makes sense but you'll also be doing a lot of > >>> acquires and releases of sched_lock. > >> > >> I must be misinterpreting this statement. Under what circumstances do > >> you spin? Yes, I read the "while the owner is running in another > >> CPU", but the way I read that, it turns the blocking lock into a spin > >> lock. > > > > Only in some cases. This is the classic way of implementing an adaptiv= e mutex. >=20 > Well, no, the classic way of implementing an adaptive lock is to spin > a little bit and then block. Alternatives would be to learn what's > going on and then decide whether to spin or block, or how long to spin > before blocking. I've never heard it applied to a choice of CPU. > Obviously any "spin lock" shouldn't spin if the lock holder is in the > same CPU. The spin only if the owner is running on another CPU is an optimization. There's no sense in spinning unconditionally when you can see if the mutex' owner is running on another CPU. This is how adaptive mutexes in Solaris work also. > > You spin if the other thread is actually executing on another CPU (the = idea > > being it will release the lock soon so you are better off avoiding the = context > > switch) and block if it is not executing on another CPU (releasing the = lock is > > already at least one context switch away, so we might as well > > switch). >=20 > If you're talking about Giant here, one of us is seriously > misunderstanding something. The whole idea of Giant is that it should > be a blocking lock, not a spin lock. Tell me I'm misunderstanding > you. The very first project milestone at http://www.freebsd.org/smp/ > read "Convert the giant lock from spinning to blocking". The spin should be very short lived if the current owner is running on another CPU. There is a lot of overhead in blocking and switching contexts, plus don't you also have to take sched lock if you block? If you know the current owner of the mutex is running on another CPU, then you should acquire the mutex within a few cycles. You have to make the assumption that mutexes are held for very short periods of time, and that there are not a lot of highly contested adaptive mutexes. > You might say "ah, but the average system call takes less time than a > schedule". We can test that. I've run lmbench on zaphod and found: >=20 > Scheduling overhead:=0918 =B5s > Null syscall (1 CPU):=09 9 =B5s > Null syscall (2 CPUs):=0957 =B5s >=20 > So this doesn't stand up. Note also that if there are more than two > CPUs, the loss of time is much more significant. --=20 Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10202210747440.22483-100000>