From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752176AbbHaAhp (ORCPT ); Sun, 30 Aug 2015 20:37:45 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:38601 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751883AbbHaAho (ORCPT ); Sun, 30 Aug 2015 20:37:44 -0400 Date: Mon, 31 Aug 2015 08:37:20 +0800 From: Boqun Feng To: Oleg Nesterov Cc: Michal Hocko , Peter Zijlstra , LKML , David Howells , Linus Torvalds , "Paul E. McKenney" , Jonathan Corbet Subject: Re: wake_up_process implied memory barrier clarification Message-ID: <20150831003719.GC924@fixme-laptop.cn.ibm.com> References: <20150827122727.GC27052@dhcp22.suse.cz> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <20150829142707.GA19263@redhat.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 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Oleg, On Sat, Aug 29, 2015 at 04:27:07PM +0200, Oleg Nesterov wrote: > Hello Boqun, >=20 =2E.. > > By this, I think you actually means the example below the added text, > > i.e. the example for "to repeat..", right? >=20 > And above. Even >=20 > The barrier occurs before the task state is cleared >=20 > is not actually right. This is misleading. What is really important is th= at > we have a barrier before we _read_ the task state. And again, again, the > fact that we actually have the write barrier is just the implementation > detail. >=20 Yes, agree with you. However, I didn't realize this problem before, I will see what I can do ;-) > > Subject: Documentation: call out conditional barriers of wait_*() and w= ake_up*() > > > > The memory barriers in some sleep and wakeup functions are conditional, > > there are several situations that there is no barriers: > > > > 1. If wait_event() and co. actually don't prepare to sleep, there > > may be no barrier in them. >=20 > And thus (imo) we should not even try to document this. I mean, a user > should not make any assumptions about the barriers inside wait_event(). >=20 Yep. > > 2. No matter whether a sleep occurs or not, there may be no barrier > > between a successful wait-condition checking(the result of which > > is true) in wait_event() and the following instructions. >=20 > Yes, this is true in any case. Not sure this deserves addtionional > documentation, but see below. >=20 > > 3. If wake_up() and co. actually wake up no one, there may be no > > write barrier in them. >=20 > See above. >=20 > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -1975,7 +1975,8 @@ set_current_state() may be wrapped by: > > > > which therefore also imply a general memory barrier after setting the = state. > > The whole sequence above is available in various canned forms, all of = which > > -interpolate the memory barrier in the right place: > > +imply a general barrier if and only if a sleep is at least about to ha= ppen, > > +i.e. prepare_to_wait*() is called. > > > > wait_event(); > > wait_event_interruptible(); > > @@ -1986,6 +1987,9 @@ interpolate the memory barrier in the right place: > > wait_on_bit(); > > wait_on_bit_lock(); > > > > +Further more, no barrier is guaranteed after the successful wait condi= tion > > +checkings, whose results are true, in wait_*() and before the instruct= ions > > +following wait_*(). >=20 > Yes, perhaps this makes sense, but (to me) only because the explanation a= bove > looks a bit confusing to me. I simply can't understand why memory-barrier= s.txt > mentions that barrier implied by set_current_state(). You need to know th= is > if you want to understand how wait_event() works. You do not need to know > about this barrier if you want to use wait_event(). If nothing else, beca= use > you can never rely on this barrier. Anf your examples below shows this. >=20 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? Thank you for your comments ;-) Regards, Boqun --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJV46G8AAoJEEl56MO1B/q4CssH/jUgFbHSkhGq2KUX7D0/dfDs BRkPd6PpdHmytPws88fD8Op0J3LSzOK9ZokhFxzOFeIhZ7F236KwwapIP2thwr0W 8Lm0KEgwpFDRG8F3qYWhpgnQpUXNTZcdsZQXqX3k3X9Q1oAkXcoO5Uhgi5nJVGab zTdPcVCeDhrKqCqd6LVv+ZzY9W222rX9zf0AG2RyyY5NXP0Lju5QKC8pRJrdXij0 x3rRaYgyqDW2jIncdG1OpZqKkDTXZ9+O4RisoOFr+mZlH8C89+4/XN6MR66fzI24 rw8K5Vyr7A6cOPTexlNID0BxERTamEOScomROfKj+I0hmpe7M3VYvtsgAFIPYTU= =jX+s -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq--