From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753866AbdF0Vs3 (ORCPT ); Tue, 27 Jun 2017 17:48:29 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:35867 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753880AbdF0VsU (ORCPT ); Tue, 27 Jun 2017 17:48:20 -0400 MIME-Version: 1.0 In-Reply-To: <20170627205802.GY3721@linux.vnet.ibm.com> References: <20170612213754.GA7201@linux.vnet.ibm.com> <20170614025404.GA2525@andrea> <20170614043317.GK3721@linux.vnet.ibm.com> <20170614143322.GA3368@andrea> <20170614202329.GV3721@linux.vnet.ibm.com> <20170619162428.GA9632@andrea> <20170627205802.GY3721@linux.vnet.ibm.com> From: Linus Torvalds Date: Tue, 27 Jun 2017 14:48:18 -0700 X-Google-Sender-Auth: -i2AcpwIeIuy1zaqBPKQ2fRCM3o Message-ID: Subject: Re: [GIT PULL rcu/next] RCU commits for 4.13 To: Paul McKenney Cc: Andrea Parri , Linux Kernel Mailing List , priyalee.kushwaha@intel.com, drozdziak1@gmail.com, Arnd Bergmann , ldr709@gmail.com, Thomas Gleixner , Peter Zijlstra , Josh Triplett , Nicolas Pitre , Krister Johansen , Vegard Nossum , dcb314@hotmail.com, Wu Fengguang , Frederic Weisbecker , Rik van Riel , Steven Rostedt , Ingo Molnar , Alan Stern , Luc Maranget , Jade Alglave Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 1:58 PM, Paul E. McKenney wrote: > > So what next? > > One option would be to weaken the definition of spin_unlock_wait() so > that it had acquire semantics but not release semantics. Alternatively, > we could keep the full empty-critical-section semantics and add memory > barriers to spin_unlock_wait() implementations, perhaps as shown in the > patch below. I could go either way, though I do have some preference > for the stronger semantics. > > Thoughts? I would prefer to just say - document that spin_unlock_wait() has acquire semantics - mindlessly add the smp_mb() to all users - let users then decide if they are ok with just acquire That's partly because I think we actually have *fewer* users than we have implementations of spin_unlock_wait(). So adding a few smp_mb()'s in the users is actually likely the smaller change. But it's also because then that allows people who *can* say that acquire is sufficient to just use it. People who use spin_unlock_wait() tend to have some odd performance reason to do so, so I think allowing them to use the more light-weight memory ordering if it works for them is a good idea. But finally, it's partly because I think "acquire" semantics are actually the saner ones that we can explain the logic for much more clearly. Basically, acquire semantics means that you are guaranteed to see any changes that were done inside a previously locked region. Doesn't that sound like sensible semantics? Then, the argument for "smp_mb()" (before the spin_unlock_wait()) becomes: - I did a write that will affect any future lock takes - the smp_mb() now means that that write will be ordered wrt the acquire that guarantees we've seen all old actions taken by a lock. Does those kinds of semantics make sense to people? Linus