Ingo, I've noticed the following situation which is caused by __up_mutex assigning an owner right away.
Given 3 processes, with priorities 1, 2, 3, where 3 is highest and 1 is lowest, and call them process A, B, C respectively. 1. Process A runs and grabs Lock L. 2. Process B preempts A, tries to grab Lock L. 3. Process A inherits process B's priority and starts to run. 4. Process C preempts A, tries to grab Lock L. 5. Process A inherits process C's priority and starts to run. 6. Process A releases Lock L loses its priority. 7. Process C gets Lock L. 8. Process C runs and releases Lock L. 9. With __up_mutex, Process B automatically gets Lock L. 10. Process C tries to grab Lock L again, but is now blocked by B. So we have a needless latency for Procss C, since it should be able to get lock L again. The problem arises because process B grabbed the lock without actually running. Since I agree with the rule that a lock can't have waiters while not being owned, I believe that this problem can be solved by adding a flag that states that the lock is "partially owned". That is the ownership of the lock should be transferred at step 9, but a flag is set that it has not been grabbed. This flag would be cleared when Process B wakes up and leaves the __down call. This way when process C tries to get the lock again, it sees that it's owned, but B hasn't executed yet. So it would be safe for C to take the lock back from B, that is if C is greater priority than B, otherwise it would act the same. If you agree with this approach, I would be willing to write a patch for you. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
