atom feed65 messages in org.freebsd.freebsd-smpRe: SMP meeting summary
FromSent OnAttachments
Jason EvansJun 24, 2000 11:56 pm 
Daniel EischenJun 25, 2000 6:58 am 
Terry LambertJun 25, 2000 10:12 am 
Terry LambertJun 25, 2000 10:36 am 
Julian ElischerJun 25, 2000 10:41 am 
Poul-Henning KampJun 25, 2000 11:07 am 
Nate WilliamsJun 25, 2000 9:41 pm 
Frank MayharJun 25, 2000 11:27 pm 
Frank MayharJun 25, 2000 11:31 pm 
Luoqi ChenJun 26, 2000 9:46 am 
Arun SharmaJun 26, 2000 9:47 am 
Jason EvansJun 26, 2000 11:06 am 
Matthew DillonJun 26, 2000 12:26 pm 
Matthew DillonJun 26, 2000 12:48 pm 
John SconiersJun 26, 2000 12:56 pm 
Matthew DillonJun 26, 2000 1:07 pm 
Luoqi ChenJun 26, 2000 1:13 pm 
Doug RabsonJun 26, 2000 1:26 pm 
Jason EvansJun 26, 2000 2:56 pm 
Jason EvansJun 26, 2000 3:14 pm 
Daniel EischenJun 26, 2000 4:59 pm 
Luoqi ChenJun 26, 2000 7:14 pm 
Jason EvansJun 26, 2000 7:55 pm 
Joe EykholtJun 26, 2000 8:09 pm 
Greg LeheyJun 27, 2000 8:00 pm 
Jason EvansJun 27, 2000 8:25 pm 
Daniel EischenJun 27, 2000 8:26 pm 
Greg LeheyJun 27, 2000 9:59 pm 
Greg LeheyJun 27, 2000 10:11 pm 
Terry LambertJun 28, 2000 4:15 pm 
Terry LambertJun 28, 2000 4:18 pm 
Terry LambertJun 28, 2000 4:37 pm 
Terry LambertJun 28, 2000 4:51 pm 
Arun SharmaJun 28, 2000 9:43 pm 
Greg LeheyJul 2, 2000 7:15 pm 
Daniel EischenJul 3, 2000 3:23 am 
Greg LeheyJul 3, 2000 3:30 am 
Jeroen C. van GelderenJul 3, 2000 7:55 am 
Chuck PatersonJul 3, 2000 8:28 am 
Chuck PatersonJul 3, 2000 8:47 am 
Frank MayharJul 3, 2000 8:49 am 
Greg LeheyJul 3, 2000 4:08 pm 
David ScheidtJul 3, 2000 4:35 pm 
Joe EykholtJul 3, 2000 4:47 pm 
Greg LeheyJul 3, 2000 4:52 pm 
Joe EykholtJul 3, 2000 4:58 pm 
Greg LeheyJul 3, 2000 5:26 pm 
Joe EykholtJul 3, 2000 5:41 pm 
Chuck PatersonJul 3, 2000 7:17 pm 
Daniel EischenJul 3, 2000 7:25 pm 
Daniel EischenJul 3, 2000 7:35 pm 
Greg LeheyJul 3, 2000 7:39 pm 
Daniel EischenJul 3, 2000 7:41 pm 
Chuck PatersonJul 3, 2000 8:40 pm 
Alfred PerlsteinJul 3, 2000 10:08 pm 
Greg LeheyJul 3, 2000 10:37 pm 
Peter WemmJul 4, 2000 2:43 pm 
Greg LeheyJul 4, 2000 3:58 pm 
Peter WemmJul 4, 2000 4:06 pm 
Terry LambertJul 5, 2000 3:38 pm 
Terry LambertJul 5, 2000 4:00 pm 
Terry LambertJul 5, 2000 4:06 pm 
Terry LambertJul 5, 2000 4:10 pm 
Alfred PerlsteinJul 5, 2000 4:29 pm 
Terry LambertJul 6, 2000 4:50 pm 
Subject:Re: SMP meeting summary
From:Greg Lehey (gr@lemis.com)
Date:Jul 3, 2000 4:08:00 pm
List:org.freebsd.freebsd-smp

On Monday, 3 July 2000 at 10:55:45 -0400, Jeroen C. van Gelderen wrote:

Greg Lehey wrote: [...]

That's an assumption. So far we have *never* had a thundering herd, because the code don't work yet.

Your position is an assumption too. The difference is that one usually doesn't optimize until one has profiling information available. Am I correct in assuming that you haven't done any profiling yet? Am I correct in assuming that wake_one is an optimization?

You're not correct in your implied assumption that we can see any potential problems with wake_one.

then waking everyone is an optimization since you only have to take the scheduling lock once.

No. If I understand things correctly, each process would need to get the schedlock, and only one process can get the mutex. Why wake the rest? What do you want them to do?

If -on average- there is only one process waiting you don't want to go trough the trouble of implementing a more complex wake_one. It would only complicate the code with negligible gain.

There's nothing to say that wake_one is more complex. wake_one takes the first process on the mutex's sleep list and wakes it. wake_all (or whatever) would make a loop out of that wake function and wake all the processes on the list. All would then be scheduled, try to take the mutex, and all except one would fail and be put back on the sleep list. Does this make sense?

That's my reading of Sun's claims in Solaris and given that they have a little more experience with this kind of thing I'm inclined to believe them until I see facts stating the contrary.

Sun's problem with Solaris is non-obvious, and may not bite us.

I think we should hold off with this kind of discussion for the while. Everything I can see suggests that it's crazy to wake all processes. If we find that we run into race conditions which we can only solve with wake_all, though, we'll compare the effort in fixing them with the (undoubted) performance degradation caused by waking them all.

Greg

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message