LKML Archive on
help / color / mirror / Atom feed
* [PATCH RFC v2] sched: completion: lock-free checking of the blocking case
@ 2015-01-24 12:49 Nicholas Mc Guire
  0 siblings, 0 replies; only message in thread
From: Nicholas Mc Guire @ 2015-01-24 12:49 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Peter Zijlstra, linux-kernel, Nicholas Mc Guire

The "thread would block" case can be checked without grabbing the lock

Signed-off-by: Nicholas Mc Guire <>

v2: return type is boot thus return should be false not 0  here
    Reported-by kbuild test robot <>    

If the check does not return early then grab the lock and recheck.
A memory barrier is not needed as complete() and complete_all() imply
a barrier.

The ACCESS_ONCE is needed for calls in a loop that, if inlined, could
optimize out the re-fetching of x->done.

 kernel/sched/completion.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 7c5cd70..5f7cf31 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -268,6 +268,15 @@ bool try_wait_for_completion(struct completion *x)
 	unsigned long flags;
 	int ret = 1;
+	/*
+	 * Since x->done will need to be locked only
+	 * in the non-blocking case, we check x->done
+	 * first without taking the lock so we can
+	 * return early in the blocking case.
+	 */
+	if (!ACCESS_ONCE(x->done))
+		return false;
 	spin_lock_irqsave(&x->wait.lock, flags);
 	if (!x->done)
 		ret = 0;

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2015-01-24 12:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-24 12:49 [PATCH RFC v2] sched: completion: lock-free checking of the blocking case Nicholas Mc Guire

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).