From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754910AbdJIOh7 (ORCPT ); Mon, 9 Oct 2017 10:37:59 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34842 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754581AbdJIOhz (ORCPT ); Mon, 9 Oct 2017 10:37:55 -0400 X-Google-Smtp-Source: AOwi7QD4VT1iEXKdnGDCDOGG8vz6B/jFdijFAegXtntMqOVS9piNMYgkGE+KBcDTLrOYLJg31Ef7kA== Date: Mon, 9 Oct 2017 16:37:44 +0200 From: Andrea Parri To: Peter Zijlstra Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com Subject: Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays Message-ID: <20171009143744.GA5238@andrea> References: <20171005161909.GS3521@linux.vnet.ibm.com> <20171005162514.moaa24mn2pkto5fv@hirez.programming.kicks-ass.net> <20171005182204.GT3521@linux.vnet.ibm.com> <20171006090723.qbcea5xnwpngrcxi@hirez.programming.kicks-ass.net> <20171006191822.GI3521@linux.vnet.ibm.com> <20171006201537.GZ6524@worktop.programming.kicks-ass.net> <20171007033105.GO3521@linux.vnet.ibm.com> <20171007092919.zusdw5e5i6wd7mf5@hirez.programming.kicks-ass.net> <20171007182857.GW3521@linux.vnet.ibm.com> <20171009081637.cpqxh27x5pqirscc@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171009081637.cpqxh27x5pqirscc@hirez.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 On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope that the memory model is applied to other tools that analyze kernel > > code. > > > > I'm not sure I got the point across; so I'll try once more. Without > > > providing this ordering the completion would be fundamentally broken. It > > > _must_ provide this ordering. > > > > OK, I now understand what you are getting at, and I do very much like > > that guarantee. > > Right, so maybe we should update the completion comments a bit to call > out this property, because I'm not sure its there. > > Also, with this, I think the smp_store_release() / smp_load_acquire() is > a perfectly fine abstraction of it, I don't think the model needs to be > taught about the completion interface. > > > > Why not? In what sort of cases does it go wobbly? > > > > For one, when it conflicts with maintainability. For example, it would > > probably be OK for some of RCU's rcu_node ->lock acquisitions to skip the > > smp_mb__after_unlock_lock() invocations. But those are slowpaths, and the > > small speedup on only one architecture is just not worth the added pain. > > Especially given the nice wrapper functions that you provided. > > > > But of course if this were instead (say) rcu_read_lock() or common-case > > rcu_read_unlock(), I would be willing to undergo much more pain. On the > > other hand, for that exact reason, that common-case code path doesn't > > acquire locks in the first place. ;-) > > Ah, so for models I would go absolutely minimal; it helps understand > what the strict requirements are and where we over-provide etc.. Except, maybe, that simplicity and maintainability do apply to "models" (design) as well... ;-) As Ingo once put it [1] (referring to the "Linux-kernel memory model"): "it's not true that Linux has to offer a barrier and locking model that panders to the weakest (and craziest!) memory ordering model amongst all the possible Linux platforms - theoretical or real metal. Instead what we want to do is to consciously, intelligently _pick_ a sane, maintainable memory model and offer primitives for that - at least as far as generic code is concerned. Each architecture can map those primitives to the best of its abilities." Andrea [1] https://marc.info/?l=linux-mm&m=138513336717990&w=2 > > For actual code you're entirely right, there's no point in trying to be > cute with the rcu-node locks. Simplicity rules etc..