From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751359AbbIAEDn (ORCPT ); Tue, 1 Sep 2015 00:03:43 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:54096 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750728AbbIAEDm (ORCPT ); Tue, 1 Sep 2015 00:03:42 -0400 X-Helo: d03dlp03.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 31 Aug 2015 21:03:36 -0700 From: "Paul E. McKenney" To: Boqun Feng Cc: Oleg Nesterov , Michal Hocko , Peter Zijlstra , LKML , David Howells , Linus Torvalds , Jonathan Corbet Subject: Re: wake_up_process implied memory barrier clarification Message-ID: <20150901040336.GA4029@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150827131444.GE27052@dhcp22.suse.cz> <20150827182654.GA12191@redhat.com> <20150828145121.GG5301@dhcp22.suse.cz> <20150828160637.GA4393@redhat.com> <20150829092514.GA3240@fixme-laptop.cn.ibm.com> <20150829142707.GA19263@redhat.com> <20150831003719.GC924@fixme-laptop.cn.ibm.com> <20150831183335.GA26333@redhat.com> <20150831203739.GX4029@linux.vnet.ibm.com> <20150901034014.GD1071@fixme-laptop.cn.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150901034014.GD1071@fixme-laptop.cn.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15090104-0029-0000-0000-00000C4FCDC6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 01, 2015 at 11:40:14AM +0800, Boqun Feng wrote: > Hi Paul, > > On Mon, Aug 31, 2015 at 01:37:39PM -0700, Paul E. McKenney wrote: > > On Mon, Aug 31, 2015 at 08:33:35PM +0200, Oleg Nesterov wrote: > > > On 08/31, Boqun Feng wrote: > > > > > > > > Fair enough, I went too far. How about just a single paragraph saying > > > > that: > > > > > > > > The wake_up(), wait_event() and their friends have proper barriers in > > > > them, but these implicity barriers are only for the correctness for > > > > sleep and wakeup. So don't rely on these barriers for things that are > > > > neither wait-conditons nor task states. > > > > > > > > Is that OK to you? > > > > > > Ask Paul ;) but personally I agree. > > > > > > To me, the only thing a user should know about wake_up/try_to_wake_up > > > and barriers is that you do not need another barrier between setting > > > condition and waking up. > > > > Sounds like an excellent idea in general. But could you please show me > > a short code snippet illustrating where you don't need the additional > > barrier, even if the fastpaths are taken so that there is no sleep and > > no wakeup? > > If there is no sleep and no wakeup, it means only CONDITION changed. > Either CONDITION is a single variable or it should maintains internal > ordering guarantee itself. And there is no need for barriers, because > there is only one shared resource we are talking about, right? I could imagine all sorts of combinations, which is why I would like to see a code snippet showing exactly what Oleg is talking about. ;-) Thanx, Paul > But I'm still a little confused at Oleg's words: > > "What is really important is that we have a barrier before we _read_ the > task state." > > I read is as "What is really important is that we have a barrier before > we _read_ the task state and _after_ we write the CONDITION", if I don't > misunderstand Oleg, this means a STORE-barrier-LOAD sequence, which IIUC > can't pair with anything. > > So, there might be some tricky barrier usage here? > > Regards, > Boqun