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
