From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752140AbbJLNJr (ORCPT ); Mon, 12 Oct 2015 09:09:47 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:35310 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbbJLNJq (ORCPT ); Mon, 12 Oct 2015 09:09:46 -0400 Date: Mon, 12 Oct 2015 21:09:24 +0800 From: Boqun Feng To: Peter Zijlstra Cc: "Paul E. McKenney" , Oleg Nesterov , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Jonathan Corbet , Michal Hocko , David Howells , Linus Torvalds , Will Deacon Subject: Re: [PATCH] Documentation: Remove misleading examples of the barriers in wake_*() Message-ID: <20151012130924.GH27351@fixme-laptop.cn.ibm.com> References: <20150909192822.GM4029@linux.vnet.ibm.com> <20150910021612.GC18494@fixme-laptop.cn.ibm.com> <20150910175557.GA20640@redhat.com> <20150917130125.GL3816@twins.programming.kicks-ass.net> <20150924132121.GA1814@fixme-laptop.cn.ibm.com> <20151006160650.GT3604@twins.programming.kicks-ass.net> <20151011152640.GC27351@fixme-laptop.cn.ibm.com> <20151012004044.GZ3910@linux.vnet.ibm.com> <20151012090636.GF27351@fixme-laptop.cn.ibm.com> <20151012115438.GM3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3xoW37o/FfUZJwQG" Content-Disposition: inline In-Reply-To: <20151012115438.GM3816@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --3xoW37o/FfUZJwQG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2015 at 01:54:38PM +0200, Peter Zijlstra wrote: > On Mon, Oct 12, 2015 at 05:06:36PM +0800, Boqun Feng wrote: > > Understood. > >=20 > > But, IMO, the position of this section is already misleading: > >=20 > > (*) Implicit kernel memory barriers. > > - Locking functions. > > - Interrupt disabling functions. > > ->- Sleep and wake-up functions.<- > > - Miscellaneous functions. > >=20 > > I read it as that sleep and wake-up functions provide some kernel memory > > barriers which we can use *externally*(outside sleep/wakeup themselves). >=20 > I think it is useful to state that the primitives handle the ordering > between the waker and wakee wrt the 'blocking' state. >=20 I agree that's useful, however, the 'blocking' state is something internal for sleep and wakeup, right? Not sure whether the users of wake_up() and wait_event() will care much about this or they need to understand that detailedly to use wake_up() and wait_event() correctly. I treat this part of memory-barriers.txt as an API document to describe the implicit barriers in some primitives, which can be used *externally* by someone, but anyway, that's just my own opinion ;-) > But I've not put much thought into wording. I wanted to finish process > order 'comment' patch first. Of course. Actually your 'comment' patch is the reason why I think this section may be removed. Regards, Boqun --3xoW37o/FfUZJwQG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJWG7EAAAoJEEl56MO1B/q4U4gIAJaKpYTFZOalh3pZPFh29qL3 CHXQa/ISuL2z05ONEHE+uFaw5Z8gZrPWwya5gwb1NPBKhQNAQjOttouY/i74XLvQ KwAh81XLVN/FkVZCz21lhdfRy3xPwNXWxvzwRNGXG2RGfMSUyK1dbNJ5gSCuEHUm xCskodDsQJnYRaMiuJLFtjdhix0jQAW3aRi4jTIckBYfZIhnFd/fKZ6nyKol2iKS ylQXLtBPeBekPD2Ie+BPwg6C0lnopyezMLUASiKk5kBsfotDOee64jK25o/v/SUV qvrwvSPJ7IztY80cCidr7vXUr30iCPryQ2gCcTRwBDEvHEYAsX2LlshpHF6Sbq8= =9SbP -----END PGP SIGNATURE----- --3xoW37o/FfUZJwQG--