Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932799AbcJTEqJ (ORCPT ); Thu, 20 Oct 2016 00:46:09 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:36077 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717AbcJTEqI (ORCPT ); Thu, 20 Oct 2016 00:46:08 -0400 Subject: Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0% To: Andrew Morton References: <20161017022504.GG22605@yexl-desktop> <1476851896-3590-1-git-send-email-manfred@colorfullife.com> <20161019172102.d04a40c4e2f9d8054aa7ec78@linux-foundation.org> Cc: LKML , Peter Zijlstra , Davidlohr Bueso , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , 1vier1@web.de, torvalds@linux-foundation.org, xiaolong.ye@intel.com, felixh@informatik.uni-bremen.de From: Manfred Spraul Message-ID: Date: Thu, 20 Oct 2016 06:46:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161019172102.d04a40c4e2f9d8054aa7ec78@linux-foundation.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2074 Lines: 54 On 10/20/2016 02:21 AM, Andrew Morton wrote: > On Wed, 19 Oct 2016 06:38:14 +0200 Manfred Spraul 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