[lkml]   [2015]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] futex: lockless wakeups

* Davidlohr Bueso <> wrote:

> 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. [...]

Please write a small description we can cite to driver authors once
the (inevitable) breakages appear, outlining this new behavior and its
implications, so that we can fix any remaining bugs ASAP.

I'll also let this pending a bit longer than other changes, to make
sure we shake out any bugs/regressions triggered by this change.

Third, it might make sense to add a new 'spurious wakeup injection
debug mechanism' that, if enabled in the .config, automatically and
continuously inserts spurious wakeups at a given, slightly randomized
rate - which would ensure that all kernel facilities can robustly
handle spurious wakeups.

My guess would be that most remaining fragilities against spurious
wakeups ought to be in the boot/init phase, so I'd keep an eye out for
suspend/resume regressions.

> [...] However there is core code that cannot handle them afaict, and
> furthermore tglx does have the point that other events can already
> trigger them anyway.

s/there is core code/there is no core code



 \ /
  Last update: 2015-04-20 08:41    [W:0.106 / U:10.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site