linux-kernel - Re: [lkp] [ipc/sem.c] 0882cba0a0: aim9.shared_memory.ops_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <714a5fac-3485-f480-1050-a4b53ba8b7fb@colorfullife.com>
Date:   Sun, 9 Oct 2016 19:30:03 +0200
From:   Manfred Spraul <manfred@...orfullife.com>
To:     kernel test robot <xiaolong.ye@...el.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...org
Subject: Re: [lkp] [ipc/sem.c] 0882cba0a0: aim9.shared_memory.ops_per_sec
 -8.8% regression

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