Re: [lkp] [ipc/sem.c] 0882cba0a0: aim9.shared_memory.ops_per_sec -8.8% regression

From: Manfred Spraul
Date: Sun Oct 09 2016 - 13:30:26 EST


Hi,

On 10/09/2016 09:05 AM, kernel test robot wrote:
FYI, we noticed a -8.8% regression of aim9.shared_memory.ops_per_sec due to commit:

commit 0882cba0a03bca73acd8fab8fb50db04691908e9 ("ipc/sem.c: fix complex_count vs. simple op race")
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

in testcase: aim9
on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 4G memory
with following parameters:

testtime: 300s
test: shared_memory
cpufreq_governor: performance

Suite IX is the "AIM Independent Resource Benchmark:" the famous synthetic benchmark.


It is probably caused by this change:
--- ipc/sem-fast-but-wrong.c 2016-10-09 19:24:47.914825410 +0200
+++ ipc/sem.c 2016-10-09 19:24:57.960841540 +0200
@@ -363,6 +363,14 @@
*/
spin_lock(&sem->lock);

+ /*
+ * See 51d7d5205d33
+ * ("powerpc: Add smp_mb() to arch_spin_is_locked()"):
+ * A full barrier is required: the write of sem->lock
+ * must be visible before the read is executed
+ */
+ smp_mb();
+
if (!smp_load_acquire(&sma->complex_mode)) {
/* fast path successful! */
return sops->sem_num;
Unfortunately, we need it, at least for powerpc.
And I do not want to add a CONFIG_PPC into ipc/sem.c.

Is it possible to do a test what happens with patch that avoids spin_unlock_wait()?

https://patchwork.kernel.org/patch/9359365/
https://patchwork.kernel.org/patch/9359371/

(if possible, with both patches together)

Thanks,
Manfred