Re: [lkp] [ipc/sem.c] 99ac0dfffc: aim9.shared_memory.ops_per_sec -8.9% regression
From: Manfred Spraul
Date: Tue Sep 06 2016 - 08:04:11 EST
Hi,
On 09/06/2016 08:42 AM, kernel test robot wrote:
FYI, we noticed a -8.9% regression of aim9.shared_memory.ops_per_sec due to commit:
commit 99ac0dfffcfb34326a880e90e06c30a2a882c692 ("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:
commit:
5ae37d6d64 ("config/android: Remove CONFIG_IPV6_PRIVACY")
99ac0dfffc ("ipc/sem.c: fix complex_count vs. simple op race")
5ae37d6d64c605ee 99ac0dfffcfb34326a880e90e0
---------------- --------------------------
fail:runs %reproduction fail:runs
| | |
%stddev %change %stddev
\ | \
1398301 ± 1% -8.9% 1274143 ± 0% aim9.shared_memory.ops_per_sec
The shared memory test uses sem_op for token passing.
I think the root cause is the additional smp_mb() after spin_lock(), at
least I got +8.9% when I removed the barrier.
#./sem_scalebench -t 30 -c 1 -p 1 -i 1 -h 4 -m 0 -d 1 -o 1 -f
(Note: Just removing the barrier is not an option)
--
Manfred
diff --git a/ipc/sem.c b/ipc/sem.c
index 5e318c5..85cc5bf 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -363,14 +363,6 @@ static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
*/
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;