Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965180AbcJSEil (ORCPT ); Wed, 19 Oct 2016 00:38:41 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33307 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933975AbcJSEij (ORCPT ); Wed, 19 Oct 2016 00:38:39 -0400 From: Manfred Spraul To: LKML , Peter Zijlstra , Davidlohr Bueso Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , 1vier1@web.de, Andrew Morton , torvalds@linux-foundation.org, xiaolong.ye@intel.com, felixh@informatik.uni-bremen.de, Manfred Spraul Subject: Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0% Date: Wed, 19 Oct 2016 06:38:14 +0200 Message-Id: <1476851896-3590-1-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <20161017022504.GG22605@yexl-desktop> References: <20161017022504.GG22605@yexl-desktop> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1380 Lines: 41 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? My initial idea was to aim for 4.10, then we have more time to decide. -- Manfred