path: root/ipc
diff options
authorDavidlohr Bueso <>2015-05-01 08:27:51 -0700
committerIngo Molnar <>2015-05-08 12:21:40 +0200
commit1d0dcb3ad9d336e6d6ee020a750a7f8d907e28de (patch)
treea5660e8c686ad11818a329efc8306d7077e47c2a /ipc
parent7675104990ed255b9315a82ae827ff312a2a88a2 (diff)
futex: Implement lockless wakeups
Given the overall futex architecture, any chance of reducing hb->lock contention is welcome. In this particular case, using wake-queues to enable lockless wakeups addresses very much real world performance concerns, even cases of soft-lockups in cases of large amounts of blocked tasks (which is not hard to find in large boxes, using but just a handful of futex). At the lowest level, this patch can reduce latency of a single thread attempting to acquire hb->lock in highly contended scenarios by a up to 2x. At lower counts of nr_wake there are no regressions, confirming, of course, that the wake_q handling overhead is practically non existent. For instance, while a fair amount of variation, the extended pef-bench wakeup benchmark shows for a 20 core machine the following avg per-thread time to wakeup its share of tasks: nr_thr ms-before ms-after 16 0.0590 0.0215 32 0.0396 0.0220 48 0.0417 0.0182 64 0.0536 0.0236 80 0.0414 0.0097 96 0.0672 0.0152 Naturally, this can cause spurious wakeups. However there is no core code that cannot handle them afaict, and furthermore tglx does have the point that other events can already trigger them anyway. Signed-off-by: Davidlohr Bueso <> Signed-off-by: Peter Zijlstra (Intel) <> Acked-by: Thomas Gleixner <> Cc: Andrew Morton <> Cc: Borislav Petkov <> Cc: Chris Mason <> Cc: Davidlohr Bueso <> Cc: George Spelvin <> Cc: H. Peter Anvin <> Cc: Linus Torvalds <> Cc: Manfred Spraul <> Cc: Peter Zijlstra <> Cc: Sebastian Andrzej Siewior <> Cc: Steven Rostedt <> Link: Signed-off-by: Ingo Molnar <>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions