[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1422103762-21916-1-git-send-email-der.herr@hofr.at>
Date: Sat, 24 Jan 2015 13:49:22 +0100
From: Nicholas Mc Guire <der.herr@...r.at>
To: Ingo Molnar <mingo@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Nicholas Mc Guire <der.herr@...r.at>
Subject: [PATCH RFC v2] sched: completion: lock-free checking of the blocking case
The "thread would block" case can be checked without grabbing the lock
Signed-off-by: Nicholas Mc Guire <der.herr@...r.at>
---
v2: return type is boot thus return should be false not 0 here
Reported-by kbuild test robot <fengguang.wu@...el.com>
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;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists