From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751637AbbFZMcc (ORCPT ); Fri, 26 Jun 2015 08:32:32 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:43610 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751877AbbFZMcY (ORCPT ); Fri, 26 Jun 2015 08:32:24 -0400 Date: Fri, 26 Jun 2015 14:32:07 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: Oleg Nesterov , tj@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, der.herr@hofr.at, dave@stgolabs.net, riel@redhat.com, viro@ZenIV.linux.org.uk, torvalds@linux-foundation.org Subject: Re: [RFC][PATCH 12/13] stop_machine: Remove lglock Message-ID: <20150626123207.GZ19282@twins.programming.kicks-ass.net> References: <20150624154010.GS19282@twins.programming.kicks-ass.net> <20150624160851.GF3717@linux.vnet.ibm.com> <20150624164200.GP3644@twins.programming.kicks-ass.net> <20150624171004.GG3717@linux.vnet.ibm.com> <20150624175830.GS3644@twins.programming.kicks-ass.net> <20150625032303.GO3717@linux.vnet.ibm.com> <20150625110734.GX3644@twins.programming.kicks-ass.net> <20150625134726.GR3717@linux.vnet.ibm.com> <20150625142011.GU19282@twins.programming.kicks-ass.net> <20150625145133.GT3717@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150625145133.GT3717@linux.vnet.ibm.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, Jun 25, 2015 at 07:51:46AM -0700, Paul E. McKenney wrote: > > So please humour me and explain how all this is far more complicated ;-) > > Yeah, I do need to get RCU design/implementation documentation put together. > > In the meantime, RCU's normal grace-period machinery is designed to be > quite loosely coupled. The idea is that almost all actions occur locally, > reducing contention and cache thrashing. But an expedited grace period > needs tight coupling in order to be able to complete quickly. Making > something that switches between loose and tight coupling in short order > is not at all simple. But expedited just means faster, we never promised that sync_rcu_expedited is the absolute fastest primitive ever. So I really should go read the RCU code I suppose, but I don't get what's wrong with starting a forced quiescent state, then doing the stop_work spray, where each work will run the regular RCU tick thing to push it forwards. >>From my feeble memories, what I remember is that the last cpu to complete a GP on a leaf node will push the completion up to the next level, until at last we've reached the root of your tree and we can complete the GP globally. To me it just makes more sense to have a single RCU state machine. With expedited we'll push it as fast as we can, but no faster.