From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755249AbbIADkg (ORCPT ); Mon, 31 Aug 2015 23:40:36 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:35571 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751579AbbIADke (ORCPT ); Mon, 31 Aug 2015 23:40:34 -0400 Date: Tue, 1 Sep 2015 11:40:14 +0800 From: Boqun Feng To: "Paul E. McKenney" 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: <20150901034014.GD1071@fixme-laptop.cn.ibm.com> References: <20150827124334.GY16853@twins.programming.kicks-ass.net> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X3gaHHMYHkYqP6yf" Content-Disposition: inline In-Reply-To: <20150831203739.GX4029@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --X3gaHHMYHkYqP6yf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? > >=20 > > Ask Paul ;) but personally I agree. > >=20 > > 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. >=20 > 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? >=20 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? 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 --X3gaHHMYHkYqP6yf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJV5R4ZAAoJEEl56MO1B/q4JYwH/034UgzxHIXKEtFUBRaEd/JE DMpVJMQUSC+y2nONfyWAWXqY3FZzrrlwKAyiQa7LT12KVwFAjI28M7uLNfu2SE5M MgTNlZifRUhtPue1awKoKH7E10NCi+kAgQjBmuprr3cQp3ulPnYO4gyor+2hOPPK DcHwqJxCokxymR2U1jyhXt9ZZID3vqy/fp3tMIu6RdjXdOlm1nEPo+6WkwX0+DKB eb6nbB0N6RmIImvjQoYZcIdh1qGkKz0FUvsFHflQ0giGr1xP1tOEPOy10VurkIlE mrLDrZ4IUQ66X5u5HedvEZslZB2rleT2gKKNJg/Ayq+bgDflXzILUW1K7xCrz1I= =ERju -----END PGP SIGNATURE----- --X3gaHHMYHkYqP6yf--