On Fri, Feb 22, 2008 at 11:55:45AM -0800, Sven-Thorsten Dietrich wrote: > > On Fri, 2008-02-22 at 11:43 -0800, Paul E. McKenney wrote: > > On Fri, Feb 22, 2008 at 11:21:14AM -0800, Bill Huey (hui) wrote: > > > On Fri, Feb 22, 2008 at 11:19 AM, Bill Huey (hui) <bill.huey@xxxxxxxxx> wrote: > > > > Yeah, I'm not very keen on having a constant there without some > > > > contention instrumentation to see how long the spins are. It would be > > > > better to just let it run until either task->on_cpu is off or checking > > > > if the "current" in no longer matches the mutex owner for the runqueue > > > > in question. At that point, you know the thread isn't running. > > > > Spinning on something like that is just a waste of time. It's for that > > > > reason that doing in the spin outside of a preempt critical section > > > > isn't really needed > > > > > > Excuse me, I meant to say "...isn't a problem". > > > > The fixed-time spins are very useful in cases where the critical section > > is almost always very short but can sometimes be very long. In such > > cases, you would want to spin until either ownership changes or it is > > apparent that the current critical-section instance will be long. > > > > I believe that there are locks in the Linux kernel that have this > > "mostly short but sometimes long" hold-time property. > > In regards to this "mostly short but sometimes long" question, > for very large SMP systems, running with some profiling enabled, might > allow the system to adapt to varying workloads and therefore shifting > lock contention / hold-times. > > Overall utilization despite the overhead might be lower, but this is > tbd. > > In high-contention, short-hold time situations, it may even make sense > to have multiple CPUs with multiple waiters spinning, depending on > hold-time vs. time to put a waiter to sleep and wake them up. > > The wake-up side could also walk ahead on the queue, and bring up > spinners from sleeping, so that they are all ready to go when the lock > flips green for them. > > But in more simple cases, there should be a simple, default timeout > governed by context switch overhead or as defined by a derived number of > cache misses, as you suggested. Governing the timeout by context-switch overhead sounds even better to me. Really easy to calibrate, and short critical sections are of much shorter duration than are a context-switch pair. Thanx, Paul > Sven > > > Thanx, Paul > > - > > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
