From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752324AbbIRGzW (ORCPT ); Fri, 18 Sep 2015 02:55:22 -0400 Received: from casper.infradead.org ([85.118.1.10]:40470 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbbIRGzV (ORCPT ); Fri, 18 Sep 2015 02:55:21 -0400 Date: Fri, 18 Sep 2015 08:49:56 +0200 From: Peter Zijlstra To: Oleg Nesterov Cc: Boqun Feng , "Paul E. McKenney" , 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: <20150918064956.GQ3816@twins.programming.kicks-ass.net> References: <1441674841-11498-1-git-send-email-boqun.feng@gmail.com> <20150909192822.GM4029@linux.vnet.ibm.com> <20150910021612.GC18494@fixme-laptop.cn.ibm.com> <20150910175557.GA20640@redhat.com> <20150917130125.GL3816@twins.programming.kicks-ass.net> <20150917170111.GA29215@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150917170111.GA29215@redhat.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 17, 2015 at 07:01:11PM +0200, Oleg Nesterov wrote: > On 09/17, Peter Zijlstra wrote: > > > > Included in it are some of the details on this subject, because a wakeup > > has two prior states that are of importance, the tasks own prior state > > and the wakeup state, both should be considered in the 'program order' > > flow. > > Great. Just one question, > > > + * BLOCKING -- aka. SLEEP + WAKEUP > > + * > > + * For blocking things are a little more interesting, because when we dequeue > > + * the task, we don't need to acquire the old rq lock in order to migrate it. > > + * > > + * Say CPU0 does a wait_event() and CPU1 does the wake() and migrates the task > > + * to CPU2 (the most complex example): > > + * > > + * CPU0 (schedule) CPU1 (try_to_wake_up) CPU2 (sched_ttwu_pending) > > + * > > + * X->state = UNINTERRUPTIBLE > > + * MB > > + * if (cond) > > + * break > > + * cond = true > > + * > > + * WMB WMB (aka smp_mb__before_spinlock) > > Yes, both CPU's do WMB-aka-smp_mb__before_spinlock... > > But afaics in this particular case we do not really need them? > So perhaps we should not even mention them? > > Because (if I am right) this can confuse the reader who will try > to understand how/where do we rely on these barriers. Good point. Initially I put all barriers in, but now that we've figured out which are important (the text is correct, right? please double check) we can remove the rest.