From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753862AbbFXPfG (ORCPT ); Wed, 24 Jun 2015 11:35:06 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:47810 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752620AbbFXPfB (ORCPT ); Wed, 24 Jun 2015 11:35:01 -0400 Date: Wed, 24 Jun 2015 17:34:50 +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: <20150624153450.GR19282@twins.programming.kicks-ass.net> References: <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> <20150623190506.GA7731@linux.vnet.ibm.com> <20150624022332.GA16620@linux.vnet.ibm.com> <20150624083257.GI3644@twins.programming.kicks-ass.net> <20150624150117.GC3717@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150624150117.GC3717@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 08:01:29AM -0700, Paul E. McKenney wrote: > On Wed, Jun 24, 2015 at 10:32:57AM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2015 at 07:23:44PM -0700, Paul E. McKenney wrote: > > > And here is an untested patch that applies the gist of your approach, > > > the series of stop_one_cpu() calls, but without undoing the rest. > > > I forged your Signed-off-by, please let me know if that doesn't work > > > for you. There are a number of simplifications that can be made, but > > > the basic approach gets a good testing first. > > > > So I really do not get the point of the trylock. It doesn't make sense. > > > > Why would you poll the mutex instead of just wait for it and then > > recheck if someone did the work while you were waiting for it? > > > > What's wrong with the below? > > Various delays can cause tasks to queue on the mutex out of order. If the mutex owner sleeps, mutexes are FIFO, otherwise things can get iffy indeed. > This can cause a given task not only to have been delayed between > sampling ->expedited_start and the mutex_lock(), but be further delayed > because tasks granted the mutex earlier will wait on grace periods that > the delayed task doesn't need to wait on. These extra waits are simply > not consistent with the "expedited" in synchronize_sched_expedited(). Feh, I really do not know if its worth optimizing the concurrent expedited case, but we could just make it an open-coded mutex that's strictly FIFO. A waitqueue on the done variable might be sufficient. That's still tons better than polling.