From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752179AbcEYGd7 (ORCPT ); Wed, 25 May 2016 02:33:59 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34613 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbcEYGd5 (ORCPT ); Wed, 25 May 2016 02:33:57 -0400 Date: Wed, 25 May 2016 14:37:37 +0800 From: Boqun Feng To: Linus Torvalds Cc: Peter Zijlstra , Davidlohr Bueso , Manfred Spraul , Waiman Long , Ingo Molnar , ggherdovich@suse.com, Mel Gorman , Linux Kernel Mailing List , Paul McKenney , Will Deacon Subject: Re: sem_lock() vs qspinlocks Message-ID: <20160525063737.GD21433@insomnia> References: <20160520053926.GC31084@linux-uzut.site> <20160520115819.GF3193@twins.programming.kicks-ass.net> <20160520140533.GA20726@insomnia> <20160520152149.GH3193@twins.programming.kicks-ass.net> <20160520160436.GQ3205@twins.programming.kicks-ass.net> <20160523122554.GH15728@worktop.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lCAWRPmW1mITcIfM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --lCAWRPmW1mITcIfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 23, 2016 at 10:52:09AM -0700, Linus Torvalds wrote: > On Mon, May 23, 2016 at 5:25 AM, Peter Zijlstra wr= ote: > > > > Paul has smp_mb__after_unlock_lock() for the RCpc 'upgrade'. How about > > something like: > > > > smp_mb__after_lock() >=20 > I'd much rather make the naming be higher level. It's not necessarily Speak of higher level, I realize that problem here is similar to the problem we discussed last year: http://lkml.kernel.org/r/20151112070915.GC6314@fixme-laptop.cn.ibm.com the problem here is about synchronization between two spinlocks and that problem is about synchronization between a spinlock and ordinary variables. (One result of this similarity is that qspinlock on x86 may be also broken in the do_exit() code as spinlocks on AARCH64 and PPC. Because a variable LOAD inside a qspinlock critical section could be reordered before the STORE part of a qspinlock acquisition.) For the problem we found last year, the current solution for AARCH64 and PPC is to have a little heavy weight spin_unlock_wait() to pair with spin_lock(): AARCH64: http://lkml.kernel.org/r/1448624646-15863-1-git-send-email-will.de= acon@arm.com PPC: http://lkml.kernel.org/r/1461130033-70898-1-git-send-email-boqun.feng@= gmail.com (not merged yet) Another solution works on PPC is what Paul Mckenney suggested, using smp_mb__after_unlock_lock(): http://lkml.kernel.org/r/20151112144004.GU3972@linux.vnet.ibm.com , which is petty much the same as the spinlock synchronization primitive we are discussing about here. So I'm thinking, if we are going to introduce some primitives for synchronizing two spinlocks (or even a spinlock and a mutex) anyway, could we be a little more higher level, to reuse/invent primitives to solve the synchronzing problem we have between spinlocks(spin_unlock_wait()) and normal variables? One benefit of this is that we could drop the complex implementations of spin_unlock_wait() on AARCH64 and PPC. Thoughts? Regards, Boqun > going to be a "mb", and while the problem is about smp, the primitives > it is synchronizing aren't actually smp-specific (ie you're > synchronizing a lock that is relevant on UP too). >=20 > So I'd just call it something like >=20 > spin_lock_sync_after_lock(); >=20 > because different locks might have different levels of serialization > (ie maybe a spinlock needs one thing, and a mutex needs another - if > we start worrying about ordering between spin_lock and > mutex_is_locked(), for example, or between mutex_lock() and > spin_is_locked()). >=20 > Hmm? >=20 > Linus --lCAWRPmW1mITcIfM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXRUgsAAoJEEl56MO1B/q4ybkH/joJJBlpGRbmcvRkWFdpqPS8 F7iS/2cLx8dxsKfSL1sekwmb0BXh7kF2y2UHD+r07a6/Dd33/yP2fg9n/DQf6Eko juah/ZiMVc80WpeXx01rzm1Hhh3/k1TJmZ0nS7FbNkmzgoRLqvWhNayAMUW74uOo 0QFfxPW9xxkT7T3pjuEzzPGpzPoH+XwdIabjj3lZqlJFgWLfUsJtby93vhC6jXbn uKl61mxMEmap90gT8WZt/CN2/3knWVER1Yr91F3AYHBzTxDot8itaCihbalXgGhA fXh7N/69uxh6BshNLEkiO1hwzOfb7ACZl8tHhRJRQmEE2oAxpIUhhjqWOxY4G3Y= =aRgH -----END PGP SIGNATURE----- --lCAWRPmW1mITcIfM--