Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: wake_futex_pi() wakes the task before releasing the hash bucket lock (HB). The first thing the woken up task usually does is to acquire the lock which requires the HB lock. On SMP Systems this leads to blocking on the HB lock which is released by the owner shortly after. This patch rearranges the unlock path by first releasing the HB lock and then waking up the task. [bigeasy: redo ontop of lockless wake-queues] Signed-off-by: Thomas Gleixner t...@linutronix.de Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- * Davidlohr Bueso | 2015-06-16 12:50:26 [-0700]: I prefer having two separate patches, thus keeping their own changelog for the change justification. okay, here it is on top of #1. A handful of boot test failures on ARM/OMAP were found by kernelci.org in next-20150619[1] and were bisected down to this patch, which hit next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the lock contention on the HB lock during wake up). I confirmed that reverting that patch on top of next-20150619 gets things booting again for the affected platforms. I haven't debugged this any further, but full boot logs are available for the boot failures[2][3] and the linux-omap list and maintainer are Cc'd here to help investigate further if needed. Kevin [1] http://kernelci.org/boot/all/job/next/kernel/next-20150619/ [2] http://storage.kernelci.org/next/next-20150619/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html [3] http://storage.kernelci.org/next/next-20150619/arm-omap2plus_defconfig/lab-tbaker/boot-omap3-beagle-xm.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
Thomas Gleixner t...@linutronix.de writes: On Fri, 19 Jun 2015, Kevin Hilman wrote: On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior A handful of boot test failures on ARM/OMAP were found by kernelci.org in next-20150619[1] and were bisected down to this patch, which hit next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the lock contention on the HB lock during wake up). I confirmed that reverting that patch on top of next-20150619 gets things booting again for the affected platforms. I haven't debugged this any further, but full boot logs are available for the boot failures[2][3] and the linux-omap list and maintainer are Cc'd here to help investigate further if needed. Found it. Dunno, how I missed that one. Fix below. Yup, that fix on top of next-20150619 gets the two OMAP platforms booting again. Tested-by: Kevin Hilman khil...@linaro.org Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
On Fri, 19 Jun 2015, Kevin Hilman wrote:
On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior
A handful of boot test failures on ARM/OMAP were found by kernelci.org
in next-20150619[1] and were bisected down to this patch, which hit
next-20150619 in the form of commit 881bd58d6e9e (futex: Lower the
lock contention on the HB lock during wake up). I confirmed that
reverting that patch on top of next-20150619 gets things booting again
for the affected platforms.
I haven't debugged this any further, but full boot logs are available
for the boot failures[2][3] and the linux-omap list and maintainer are
Cc'd here to help investigate further if needed.
Found it. Dunno, how I missed that one. Fix below.
Thanks,
tglx
---
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 10dbeb6fe96f..5674b073473c 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1365,9 +1365,14 @@ rt_mutex_fastunlock(struct rt_mutex *lock,
if (likely(rt_mutex_cmpxchg(lock, current, NULL))) {
rt_mutex_deadlock_account_unlock(current);
- } else if (slowfn(lock, wake_q)) {
+ } else {
+ bool deboost = slowfn(lock, wake_q);
+
+ wake_up_q(wake_q);
+
/* Undo pi boosting if necessary: */
- rt_mutex_adjust_prio(current);
+ if (deboost)
+ rt_mutex_adjust_prio(current);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
