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

[Manfred Spraul]

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