From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161205AbdAEJvb (ORCPT ); Thu, 5 Jan 2017 04:51:31 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:34593 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S970442AbdAEJvS (ORCPT ); Thu, 5 Jan 2017 04:51:18 -0500 Date: Thu, 5 Jan 2017 17:51:11 +0800 From: Boqun Feng To: Pan Xinhui Cc: Peter Zijlstra , Waiman Long , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs Message-ID: <20170105095055.GC15084@tardis.cn.ibm.com> References: <1482697561-23848-1-git-send-email-longman@redhat.com> <20170103161836.GY3107@twins.programming.kicks-ass.net> <20170104094149.GD25813@worktop.programming.kicks-ass.net> <006322ad-2e72-c8fe-361f-233f1821063a@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lteA1dqeVaWQ9QQl" Content-Disposition: inline In-Reply-To: <006322ad-2e72-c8fe-361f-233f1821063a@linux.vnet.ibm.com> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --lteA1dqeVaWQ9QQl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 05, 2017 at 04:16:38PM +0800, Pan Xinhui wrote: >=20 >=20 > =E5=9C=A8 2017/1/4 17:41, Peter Zijlstra =E5=86=99=E9=81=93: > > On Tue, Jan 03, 2017 at 05:07:54PM -0500, Waiman Long wrote: > > > On 01/03/2017 11:18 AM, Peter Zijlstra wrote: > > > > On Sun, Dec 25, 2016 at 03:26:01PM -0500, Waiman Long wrote: > > > > > A number of cmpxchg calls in qspinlock_paravirt.h were replaced b= y more > > > > > relaxed versions to improve performance on architectures that use= LL/SC. > > > > Claim without numbers ;-) > > >=20 > > > Well it is hard to produce actual numbers here as I don't have the se= tup > > > to gather data. > >=20 > > Surely RHT has big PPC machines around? I know that getting to them is a > > wee bit of a bother, but they should be available somewhere. > >=20 > hi, >=20 > I do some tests about cmpxchg and cmpxchg_acquire before on ppc. >=20 > loops in 15s of each cmpxchg is below. >=20 > cmpxchg_relaxed: 336663 > cmpxchg_release: 369054 > cmpxchg_acquire: 363364 > cmpxchg: 179435 >=20 > so cmpxchg is really expensive than others. > but I also have doubt about the cmpxchg_relaxed, it should be the cheapes= t, but from the tests, release/acquire are faster than it. >=20 I have observed something similar before. But the performance number for a single atomic operation itself is not that useful. Here is my understanding(basically guessing ;-)) If your testcase is only committing those cmpxchg in a loop then the overhead of the barrier in _release and _acquire is much small and may even help the performance because of their side effects on prefetchs or cache invalidations. But if your testcase get complex even that committing barriers is not cheap, you probably will see cmpxchg_relaxed beats _acquire and _release variants. Regards, Boqun > thanks > xinhui >=20 --lteA1dqeVaWQ9QQl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlhuFwsACgkQSXnow7UH +rjHKwf/XdfsxVUCqys1jugiJrgPe5EgZi/j1MN/3R6KceOLJIrJq8z1BWJ2tJ5a 8AAgUJZl+oiybCM8VUpeq8pqa+ZKOYascx3opHCiikKZQqwyKsylZ2n1948MsxW4 B7W4KjJOEox/imMNlG07fbhRZJuNielNqiqwxnZsC+821n3KJbUOjW4yi5MAy0mX rM2+GW+2ro43NRwgleLG0QM89rSl52JCBe9CYxkRknxlcX3Tww2/i175c5Gv9AZZ f0JL9O26ht3cmTEPaFdk1/wqL6Dsp0j6zIWucV6J3o7Ezt+vkvh0T0TIDAKS8/5W 4M4it+53Lasx1tow7a/myWYxCtP6mw== =SdLW -----END PGP SIGNATURE----- --lteA1dqeVaWQ9QQl--