On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: > > On 21-Feb-02 Greg Lehey wrote: >> On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: >>> Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, >>> Matthew Dillon said words to the effect of; >>>> I'm fairly sure JHB does not have a patch to address this but, please, >>>> be my guest and check P4. >>> >>> Actually he does. Maybe you should have checked p4 first yourself. >> >> Well, maybe, like me, he doesn't know how. I only recently learnt of >> the existence of this repo, and I still don't know where it is. It >> certainly wasn't announced on the SMP mailing list. I've seen a few >> references to p4 there, but no indication of how to access the repo. >> >>> 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 adaptive mutex.
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. > 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). 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". 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: Scheduling overhead: 18 µs Null syscall (1 CPU): 9 µs Null syscall (2 CPUs): 57 µs So this doesn't stand up. Note also that if there are more than two CPUs, the loss of time is much more significant. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
