On Tue, 2013-11-26 at 13:34 +0100, Thomas Gleixner wrote: > On Tue, 26 Nov 2013, Peter Zijlstra wrote: > > > On Tue, Nov 26, 2013 at 12:21:40PM +0100, Ingo Molnar wrote: > > > I'm somewhat reluctant to chalk it up to a single mfence - maybe > > > timings/behavior changed in some substantial way? > > > > Ah indeed! We also changed the case where an enqueueing futex sees the > > uval change and bails. It is now far more expensive due to having to > > both queue and unqueue, whereas before it wouldn't queue at all. > > > > I suppose the idea was to offset that by not requiring locking on the > > wake side. > > Aside of that I really would be interrested in an explanation for the > STDDEV going up by factor 5. That's a clear indicator for fishyness.
FWIW here's another run for the patched kernel, stddev went down to ~3, yet the overhead is quite similar to original results: Run summary [PID 17678]: blocking on 512 threads (at futex 0x60314c), waking up 1 at a time. [Run 1]: Wokeup 512 of 512 threads (100.00%) in 14.0360 ms [Run 2]: Wokeup 512 of 512 threads (100.00%) in 15.6660 ms [Run 3]: Wokeup 512 of 512 threads (100.00%) in 13.9330 ms [Run 4]: Wokeup 512 of 512 threads (100.00%) in 18.5790 ms [Run 5]: Wokeup 512 of 512 threads (100.00%) in 14.1480 ms [Run 6]: Wokeup 512 of 512 threads (100.00%) in 14.5930 ms [Run 7]: Wokeup 512 of 512 threads (100.00%) in 13.4360 ms [Run 8]: Wokeup 512 of 512 threads (100.00%) in 10.0730 ms [Run 9]: Wokeup 512 of 512 threads (100.00%) in 16.9040 ms [Run 10]: Wokeup 512 of 512 threads (100.00%) in 19.3800 ms Wokeup 512 of 512 threads (100.00%) in 15.0700 ms Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/