Messages in this thread | | | Date | Wed, 26 Oct 2016 09:15:19 +0000 | From | Nicholas Mc Guire <> | Subject | Re: complete_all and "forever" completions |
| |
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
| |