From: Mike Galbraith <bitbucket@online.de>
To: linux-rt-users <linux-rt-users@vger.kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: [PATCH RT] rt,ipc,sem: fix -rt livelock
Date: Fri, 30 Aug 2013 16:39:40 +0200 [thread overview]
Message-ID: <1377873580.5422.25.camel@marge.simpson.net> (raw)
In-Reply-To: <1377842245.5422.7.camel@marge.simpson.net>
Greetings,
The semaphore scalability changes have a less than wonderful trait for
-rt. The below.. makes it not do that. I originally did this to test
(and actually survive) scalability patches backported to 3.0-rt on a 64
core box, and was just rudely reminded of the problem after putting
3.10-rt onto the same box for latency comparison.
goto again loop can and does induce livelock in -rt. Remove it.
Signed-off-by: Mike Galbraith <bitbucket@online.de>
---
ipc/sem.c | 56 ++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 38 insertions(+), 18 deletions(-)
Index: linux-2.6/ipc/sem.c
===================================================================
--- linux-2.6.orig/ipc/sem.c
+++ linux-2.6/ipc/sem.c
@@ -208,22 +208,11 @@ void __init sem_init (void)
static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
int nsops)
{
+ struct sem *sem;
int locknum;
- again:
- if (nsops == 1 && !sma->complex_count) {
- struct sem *sem = sma->sem_base + sops->sem_num;
-
- /* Lock just the semaphore we are interested in. */
- spin_lock(&sem->lock);
- /*
- * If sma->complex_count was set while we were spinning,
- * we may need to look at things we did not lock here.
- */
- if (unlikely(sma->complex_count)) {
- spin_unlock(&sem->lock);
- goto lock_array;
- }
+ if (nsops == 1 && !sma->complex_count) {
+ sem = sma->sem_base + sops->sem_num;
/*
* Another process is holding the global lock on the
@@ -231,9 +220,29 @@ static inline int sem_lock(struct sem_ar
* but have to wait for the global lock to be released.
*/
if (unlikely(spin_is_locked(&sma->sem_perm.lock))) {
- spin_unlock(&sem->lock);
- spin_unlock_wait(&sma->sem_perm.lock);
- goto again;
+ spin_lock(&sma->sem_perm.lock);
+ if (sma->complex_count)
+ goto wait_array;
+
+ /*
+ * Acquiring our sem->lock under the global lock
+ * forces new complex operations to wait for us
+ * to exit our critical section.
+ */
+ spin_lock(&sem->lock);
+ spin_unlock(&sma->sem_perm.lock);
+ } else {
+ /* Lock just the semaphore we are interested in. */
+ spin_lock(&sem->lock);
+
+ /*
+ * If sma->complex_count was set prior to acquisition,
+ * we must fall back to the global array lock.
+ */
+ if (unlikely(sma->complex_count)) {
+ spin_unlock(&sem->lock);
+ goto lock_array;
+ }
}
locknum = sops->sem_num;
@@ -247,11 +256,22 @@ static inline int sem_lock(struct sem_ar
*/
lock_array:
spin_lock(&sma->sem_perm.lock);
+ wait_array:
for (i = 0; i < sma->sem_nsems; i++) {
- struct sem *sem = sma->sem_base + i;
+ sem = sma->sem_base + i;
+#ifdef CONFIG_PREEMPT_RT_BASE
+ if (spin_is_locked(&sem->lock))
+#endif
spin_unlock_wait(&sem->lock);
}
locknum = -1;
+
+ if (nsops == 1 && !sma->complex_count) {
+ sem = sma->sem_base + sops->sem_num;
+ spin_lock(&sem->lock);
+ spin_unlock(&sma->sem_perm.lock);
+ locknum = sops->sem_num;
+ }
}
return locknum;
}
next prev parent reply other threads:[~2013-08-30 14:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-19 21:33 [PATCH RT 0/3] hwlat-detector: Have it actually find hardware latency Steven Rostedt
2013-08-19 21:33 ` [PATCH RT 1/3] hwlat-detector: Update hwlat_detector to add outer loop detection Steven Rostedt
2013-08-19 21:33 ` [PATCH RT 2/3] hwlat-detector: Use trace_clock_local if available Steven Rostedt
2013-08-19 21:33 ` [PATCH RT 3/3] hwlat-detector: Use thread instead of stop machine Steven Rostedt
2013-08-21 15:59 ` [PATCH RT 0/3] hwlat-detector: Have it actually find hardware latency Sebastian Andrzej Siewior
2013-08-30 5:57 ` [PATCH RT] hwlat-detector: Don't ignore threshold module parameter Mike Galbraith
2013-08-30 14:39 ` Mike Galbraith [this message]
2013-08-31 5:27 ` [PATCH RT] rt,ipc,sem: fix -rt livelock Mike Galbraith
2013-09-06 7:08 ` Mike Galbraith
2013-09-10 6:30 ` Mike Galbraith
2013-09-11 14:03 ` Manfred Spraul
2013-09-12 7:40 ` Mike Galbraith
2013-09-12 19:15 ` Steven Rostedt
2013-09-13 3:20 ` Mike Galbraith
2013-09-13 3:33 ` Steven Rostedt
2013-09-13 4:48 ` Mike Galbraith
2013-09-13 4:36 ` Mike Galbraith
2013-09-13 12:56 ` Mike Galbraith
2013-09-12 18:23 ` [PATCH RT] hwlat-detector: Don't ignore threshold module parameter Steven Rostedt
2013-10-04 10:30 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1377873580.5422.25.camel@marge.simpson.net \
--to=bitbucket@online.de \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.