Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756595AbcJZJPx (ORCPT ); Wed, 26 Oct 2016 05:15:53 -0400 Received: from mail.osadl.at ([92.243.35.153]:60652 "EHLO mail.osadl.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750833AbcJZJPt (ORCPT ); Wed, 26 Oct 2016 05:15:49 -0400 Date: Wed, 26 Oct 2016 09:15:19 +0000 From: Nicholas Mc Guire To: Peter Zijlstra Cc: Dmitry Torokhov , LKML , Tejun Heo , computersforpeace@gmail.com, Ingo Molnar Subject: Re: complete_all and "forever" completions Message-ID: <20161026091519.GA577@osadl.at> References: <20161025223054.GA22917@dtor-ws> <20161026084535.GX3102@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161026084535.GX3102@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2230 Lines: 58 On Wed, Oct 26, 2016 at 10:45:35AM +0200, Peter Zijlstra wrote: > On Tue, Oct 25, 2016 at 03:30:54PM -0700, Dmitry Torokhov wrote: > > Hi, > > > > Reading Documentation/scheduler/completion.txt, complete_all() is > > Oh, there is documentation? /me goes read. > > > supposed to be usable with "forever" completions, i.e. when we have an > > action that happens once and stays "done" for the rest of lifetime of an > > object, no matter how many times we check for "doneness". > > I suppose you allude to this wording: > > "calls complete_all() to signal all current and future waiters." > > > However the > > implementation for complete_all() simply sets the counter to be greater > > or equal UINT_MAX/2 and do_wait_for_common() happily decreases it on > > every call. > > This is indeed so. > > > Is it simply an artefact of [older] implementation where we do not > > expect to make that many calls to wait_for_completion*() so that > > completion that is signalled with ocmplete_all() is practically stays > > signalled forever? > > The text says it was written against v3.18 or thereabout, and that > implementation looks a lot like todays, so I doubt it ever worked like > that. bad wording maybe - the intent of setting it to UINT_MAX/2 as far as I can judge is though that UINT_MAX/2 effectively would be infinity in practice. Is it realistic to assume that there would be a complete_all() call followed by 2147483648 calls to wait_for_completion() ? The note on "future waiters" was to make it clear that once you called complete_all() future wait_for_completion() have no synchronizing effect. > > > Or do we need something like this in > > do_wait_for_common(): > > > > if (x->done < UINT_MAX/2) > > x->done--; > > Depends a bit, do you really want this? Seems a bit daft to keep asking > if its done already, seems like a waste of cycles to me. > I would claim that if you have a complete_all() (done=2147483648) and you actually did manage to decrement it to 0 over time so a call finally blocks (presumably for ever) this would be uncovering a deisgn bug in the use of completion as such a setup does not make any sense (Or Im just not creative enough to think of such a situation). thx! hofrat