From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752960AbbFXPC0 (ORCPT ); Wed, 24 Jun 2015 11:02:26 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:46600 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752888AbbFXPCR (ORCPT ); Wed, 24 Jun 2015 11:02:17 -0400 Date: Wed, 24 Jun 2015 17:01:51 +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: <20150624150151.GN3644@twins.programming.kicks-ass.net> References: <20150622222152.GA4460@redhat.com> <20150623100932.GB3644@twins.programming.kicks-ass.net> <20150623105548.GE18673@twins.programming.kicks-ass.net> <20150623112041.GF18673@twins.programming.kicks-ass.net> <20150623130826.GG18673@twins.programming.kicks-ass.net> <20150623173038.GJ3892@linux.vnet.ibm.com> <20150623180411.GF3644@twins.programming.kicks-ass.net> <20150623182626.GO3892@linux.vnet.ibm.com> <20150624073503.GH3644@twins.programming.kicks-ass.net> <20150624145030.GB3717@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150624145030.GB3717@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 Wed, Jun 24, 2015 at 07:50:42AM -0700, Paul E. McKenney wrote: > On Wed, Jun 24, 2015 at 09:35:03AM +0200, Peter Zijlstra wrote: > > I still don't see a problem here though; the stop_one_cpu() invocation > > for the CPU that's suffering its preemption latency will take longer, > > but so what? > > > > How does polling and dropping back to sync_rcu() generate better > > behaviour than simply waiting for the completion? > > Because if there is too much delay, synchronize_rcu() is no slower > than is synchronize_rcu_expedited(), plus synchronize_rcu() is much > more efficient. Still confused.. How is polling and then blocking more efficient than just blocking in the first place? I'm seeing the polling as a waste of cpu time. The thing is, if we're stalled on a stop_one_cpu() call, the sync_rcu() is equally stalled. The sync_rcu() cannot wait more efficient than we're already waiting either.