On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote: > > Your patches only do avoiding the wq issue now we focus on. > > > > Look at: > > > > worker thread another context > > ------------- --------------- > > wait_for_completion() > > | > > | (1) > > v > > +---------+ > > | Work A | (2) > > +---------+ > > | > > | (3) > > v > > +---------+ > > | Work B | (4) > > +---------+ > > | > > | (5) > > v > > +---------+ > > | Work C | (6) > > +---------+ > > | > > v > > > > We have to consider whole context of the worker to build dependencies > > with a crosslock e.g. wait_for_commplete(). > > > > Only thing we have to care here is to make all works e.g. (2), (4) and > > (6) independent, because workqueue does _concurrency control_. As I said > > last year at the very beginning, for works not applied the control e.g. > > max_active == 1, we don't need that isolation. I said, it's a future work. > > > > It would have been much easier to communicate with each other if you > > *tried* to understand my examples like now or you *tried* to give me one > > example at least. You didn't even *try*. Only thing I want to ask you > > for is to *try* to understand my opinions on conflicts. > > > > Now, understand what I intended? Still unsufficient? > > So you worry about max_active==1 ? Or you worry about pool->lock or > about the thread setup? I'm still not sure.
It's close to the letter. Precisely, I worry about (1), (3), (5) and so on, since they certainly create dependencies with crosslocks e.g. completion in my example.
