As someone else already pointed out once the OS starts to run there is a whole lot of tuning that needs to go on to choose a mix of compromises that works reasonable with the "general" work load. There have been lots of good suggestions made, which need to be considered once we have something up and running and have accumulated some data.

}Well if you are considering spinning for a bit of time on a held }mutex (which you seem to advocate?), then why not wake everyone? }If mutexes are held for very short periods of time and you don't }often have a thundering herd problem, then waking everyone is }an optimization since you only have to take the scheduling lock }once. If mutexes can be held for long periods of time, then you }probably wouldn't want to wake everyone. } }-- }Dan Eischen

If all processes are made runnable at once then both future releases and acquisitions of the mutex may be uncontested, resulting in not having to acquire the scheduling lock. If the system is busy and there are not idle CPUs then there won't be a thundering herd, because there is no herd to thunder. The probability of threads blocking on the mutex before it is released is a function of mutex hold time to the time it takes a processor to calling switch with the thread which wants to run being the highest priority. In general mutex hold time is small compared to the time a process runs.

Only a single free processor is required to cause a problem when priority inversion has occurred and multiple threads are waiting on the mutex. Both the processor doing the release and the free processor will be picking off the run queue and potentially picking threads which want the same mutex.

If someone wanted/needed to build a system where prioritization is so important that processes are preempted even if they are on another processor then making processes, which are just going to block immediately, runnable is going to be very bad. This too can most likely be solved with only a single added test in the path of a contested release.

In general there ought not to be multiple processes piling up on a mutex. If there are and for some reason they can't be fixed then these particular mutexs are going to dictate how this area is handled. Once we have these cases in hand we can make some decisions as to how to proceed.

Chuck

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