linux-kernel - Re: [lkp] [ipc/sem.c] 5864a2fd30: 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] [day] [month] [year] [list]

Date:   Thu, 20 Oct 2016 06:46:03 +0200
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        1vier1@....de, torvalds@...ux-foundation.org,
        xiaolong.ye@...el.com, felixh@...ormatik.uni-bremen.de
Subject: Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec
 -13.0%

On 10/20/2016 02:21 AM, Andrew Morton wrote:
> On Wed, 19 Oct 2016 06:38:14 +0200 Manfred Spraul <manfred@...orfullife.com> wrote:
>
>> Hi,
>>
>> as discussed before:
>> The root cause for the performance regression is the smp_mb() that was
>> added into the fast path.
>>
>> I see two options:
>> 1) switch to full spin_lock()/spin_unlock() for the rare codepath,
>>    then the fast path doesn't need the smp_mb() anymore.
>>
>> 2) confirm that no arch needs the smp_mb(), then remove it.
>>    - powerpc is ok after commit
>>       6262db7c088b ("powerpc/spinlock: Fix spin_unlock_wait()")
>>    - arm is ok after commit
>>       d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers")
>>    - for x86 is ok after commit
>>       2c6100227116 ("locking/qspinlock: Fix spin_unlock_wait() some more")
>>    - for the remaining SMP architectures, I don't have a status.
>>
>> I would prefer the approach 1:
>> The memory ordering provided by spin_lock()/spin_unlock() is clear.
>>
>> Thus:
>> Attached are patches for approach 1:
>>
>> - Patch 1 replaces spin_unlock_wait() with spin_lock()/spin_unlock() and
>>    removes all memory barriers that are then unnecessary.
>>
>> - Patch 2 adds the hysteresis code: This makes the rare codepath
>>    extremely rare.
>>    It also corrects some wrong comments, e.g. regarding switching
>>    from global lock to per-sem lock (we "must' switch, not we "can"
>>    switch as written right now).
>>
>> The patches passed stress-testing.
>>
>> What do you think?
> Are you able to confirm that the performance issues are fixed?
I don't know why we are now at -13%.
The previous -9% were resolved by the patches:

http://marc.info/?l=linux-kernel&m=147608082017551&w=2
>> My initial idea was to aim for 4.10, then we have more time to decide.
> I suppose I can slip these into -next and see what the effect is upon
> the Intel test results.  But a) I don't know if they test linux-next(?)
> and b) I don't know where the test results are published, assuming they
> are published(?).

--

     Manfred