Messages in this thread |  | | Subject | Re: [lkp] [ipc/sem.c] 0882cba0a0: aim9.shared_memory.ops_per_sec -8.8% regression | From | Manfred Spraul <> | Date | Sun, 9 Oct 2016 19:30:03 +0200 |
| |
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
|  |