On Wed, Sep 06, 2017 at 10:32:54AM +0900, Byungchul Park wrote:
> > What do you mean by "false dependencies"? AFAICT, recursive-read could
>
> All locks used in every work->func() generate false dependencies with
> 'work' and 'wq', while any flush works are not involved. It's inevitable.
>
> More
On Wed, Sep 06, 2017 at 10:32:54AM +0900, Byungchul Park wrote:
> Moreover, it's also possible to generate more false ones between the
> pseudo acquisitions, if real acquisitions are used for that speculative
> purpose e.i. recursive-read here, which are anyway real ones.
Of course, this problem c
On Wed, Sep 06, 2017 at 08:42:11AM +0800, Boqun Feng wrote:
> > OK. If the workqueue is only user of the weird lockdep annotations, then
> > it might be better to defer introducing the extra state until needed.
> >
> > But, the 'might' thing I introduced would be necessary if more users
> > want t
On Tue, Sep 05, 2017 at 03:46:43PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 07:58:38PM +0900, Byungchul Park wrote:
> > On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> > > Recursive-read and the hint I proposed(a.k.a. might) should be used for
> > > their different s
On Wed, Sep 06, 2017 at 08:52:35AM +0900, Byungchul Park wrote:
> On Tue, Sep 05, 2017 at 03:46:43PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 05, 2017 at 07:58:38PM +0900, Byungchul Park wrote:
> > > On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> > > > Recursive-read and the
On Tue, Sep 05, 2017 at 03:46:43PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 07:58:38PM +0900, Byungchul Park wrote:
> > On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> > > Recursive-read and the hint I proposed(a.k.a. might) should be used for
> > > their different s
On Tue, Sep 05, 2017 at 07:58:38PM +0900, Byungchul Park wrote:
> On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> > Recursive-read and the hint I proposed(a.k.a. might) should be used for
> > their different specific applications. Both meaning and constraints of
> > them are total
On Tue, Sep 05, 2017 at 12:52:36PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> > Let me show you a possible scenario with a leaf lock:
> >
> > lock(A)
> >lock(A) wait_for_completion(B)
> >unlock(A)
On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> Recursive-read and the hint I proposed(a.k.a. might) should be used for
> their different specific applications. Both meaning and constraints of
> them are totally different.
>
> Using a right function semantically is more important
On Tue, Sep 05, 2017 at 07:31:44PM +0900, Byungchul Park wrote:
> Let me show you a possible scenario with a leaf lock:
>
> lock(A)
>lock(A) wait_for_completion(B)
>unlock(A)...
>... unlock(A)
>process_one_work()
>
On Tue, Sep 05, 2017 at 11:36:24AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 05:57:27PM +0900, Byungchul Park wrote:
> > On Tue, Sep 05, 2017 at 09:19:30AM +0200, Peter Zijlstra wrote:
> > > On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote:
> > > > So you worry about max_
On Tue, Sep 05, 2017 at 05:57:27PM +0900, Byungchul Park wrote:
> On Tue, Sep 05, 2017 at 09:19:30AM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote:
> > > So you worry about max_active==1 ? Or you worry about pool->lock or
> > > about the thread setu
On Tue, Sep 05, 2017 at 09:19:30AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote:
> > So you worry about max_active==1 ? Or you worry about pool->lock or
> > about the thread setup? I'm still not sure.
>
> So the thing about pool->lock is that its a
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
> > - ---
> >
On Tue, Sep 05, 2017 at 09:08:25AM +0200, Peter Zijlstra wrote:
> So you worry about max_active==1 ? Or you worry about pool->lock or
> about the thread setup? I'm still not sure.
So the thing about pool->lock is that its a leaf lock, we take nothing
inside it. Futhermore its a spinlock and theref
On Tue, Sep 05, 2017 at 09:38:45AM +0900, Byungchul Park wrote:
> On Mon, Sep 04, 2017 at 01:42:48PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote:
> > > On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote:
> > > > And get tangled up with
On Mon, Sep 04, 2017 at 01:42:48PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote:
> > On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote:
> > > And get tangled up with the workqueue annotation again, no thanks.
> > > Having the first few w
On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote:
> On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote:
> > And get tangled up with the workqueue annotation again, no thanks.
> > Having the first few works see the thread setup isn't worth it.
> >
> > And your work_id anno
On Mon, Sep 04, 2017 at 10:30:32AM +0900, Byungchul Park wrote:
> On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 01, 2017 at 10:51:48PM +0900, Byungchul Park wrote:
> > > On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra
> > > wrote:
> > > > On Fri, Sep 01, 2017 at 0
On Fri, Sep 01, 2017 at 06:38:52PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 10:51:48PM +0900, Byungchul Park wrote:
> > On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra wrote:
> > > On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote:
> > >
> > >> It would be gone _only_ at
On Fri, Sep 01, 2017 at 10:51:48PM +0900, Byungchul Park wrote:
> On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra wrote:
> > On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote:
> >
> >> It would be gone _only_ at the time the history overrun, and then it
> >> will be built again. So, yo
On Fri, Sep 1, 2017 at 9:38 PM, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote:
>
>> It would be gone _only_ at the time the history overrun, and then it
>> will be built again. So, you are wrong.
s/it will be built again/the acquisition will be added into
On Fri, Sep 01, 2017 at 07:16:29PM +0900, Byungchul Park wrote:
> It would be gone _only_ at the time the history overrun, and then it
> will be built again. So, you are wrong.
How will it ever be build again? You only ever spawn the worker thread
_ONCE_, then it runs lots and lots of works.
We
.com; linux-
> ker...@vger.kernel.org; kernel-t...@lge.com
> Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
>
> On Fri, Sep 01, 2017 at 11:47:47AM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 01, 2017 at 11:05:12AM +0900, Byungchul Park wrote:
> > > On
On Fri, Sep 01, 2017 at 11:47:47AM +0200, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 11:05:12AM +0900, Byungchul Park wrote:
> > On Thu, Aug 31, 2017 at 10:34:53AM +0200, Peter Zijlstra wrote:
> > > On Thu, Aug 31, 2017 at 05:15:01PM +0900, Byungchul Park wrote:
> > > > It's not important. Ok,
On Fri, Sep 01, 2017 at 11:05:12AM +0900, Byungchul Park wrote:
> On Thu, Aug 31, 2017 at 10:34:53AM +0200, Peter Zijlstra wrote:
> > On Thu, Aug 31, 2017 at 05:15:01PM +0900, Byungchul Park wrote:
> > > It's not important. Ok, check the following, instead:
> > >
> > > context X co
On Thu, Aug 31, 2017 at 10:34:53AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 31, 2017 at 05:15:01PM +0900, Byungchul Park wrote:
> > It's not important. Ok, check the following, instead:
> >
> > context X context Y
> > - -
> >
On Thu, Aug 31, 2017 at 05:15:01PM +0900, Byungchul Park wrote:
> It's not important. Ok, check the following, instead:
>
> context X context Y
> - -
> wait_for_completion(C)
> acquire(A)
> release(A)
> process_one_work()
>
On Thu, Aug 31, 2017 at 10:04:42AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 30, 2017 at 08:25:46PM +0900, Byungchul Park wrote:
>
> > For example - I'm giving you the same example repeatedly:
> >
> > context X context Y
> > - -
> >
On Wed, Aug 30, 2017 at 06:24:39PM +0900, Byungchul Park wrote:
> > And there obviously _should_ not be any dependencies between those. A
>
> 100% right. Since there obviously should not be any, it would be better
> to check them. So I've endlessly asked you 'do you have any reason removing
> the
On Wed, Aug 30, 2017 at 08:25:46PM +0900, Byungchul Park wrote:
> For example - I'm giving you the same example repeatedly:
>
> context X context Y
> - -
> wait_for_completion(C)
> acquire(A)
> process_one_work()
>acqui
12 PM
> > > To: Byungchul Park
> > > Cc: mi...@kernel.org; t...@kernel.org; boqun.f...@gmail.com;
> > > da...@fromorbit.com; johan...@sipsolutions.net; o...@redhat.com; linux-
> > > ker...@vger.kernel.org; kernel-t...@lge.com
> > > Subject: Re: [PATCH 4/4] lockd
gt; > To: Byungchul Park
>> > Cc: mi...@kernel.org; t...@kernel.org; boqun.f...@gmail.com;
>> > da...@fromorbit.com; johan...@sipsolutions.net; o...@redhat.com; linux-
>> > ker...@vger.kernel.org; kernel-t...@lge.com
>> > Subject: Re: [PATCH 4/4] lockdep: Fix wor
; boqun.f...@gmail.com;
> > da...@fromorbit.com; johan...@sipsolutions.net; o...@redhat.com; linux-
> > ker...@vger.kernel.org; kernel-t...@lge.com
> > Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
> >
> > On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byu
.com; linux-
> ker...@vger.kernel.org; kernel-t...@lge.com
> Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
>
> On Wed, Aug 30, 2017 at 11:12:23AM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote:
> > >
.com; linux-
> ker...@vger.kernel.org; kernel-t...@lge.com
> Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
>
> On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote:
> > My point is that we inevitably lose valuable dependencies by yours.
> That's
&
On Wed, Aug 30, 2017 at 11:12:23AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote:
> > My point is that we inevitably lose valuable dependencies by yours. That's
> > why I've endlessly asked you 'do you have any reason you try those patches?'
> > a ton
On Wed, Aug 30, 2017 at 06:01:59PM +0900, Byungchul Park wrote:
> My point is that we inevitably lose valuable dependencies by yours. That's
> why I've endlessly asked you 'do you have any reason you try those patches?'
> a ton of times. And you have never answered it.
The only dependencies that a
.com; linux-
> ker...@vger.kernel.org; kernel-t...@lge.com
> Subject: Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
>
> On Wed, Aug 30, 2017 at 04:41:17PM +0900, Byungchul Park wrote:
> > On Wed, Aug 30, 2017 at 11:09:53AM +0900, Byungchul Park wrote:
>
>
On Wed, Aug 30, 2017 at 04:41:17PM +0900, Byungchul Park wrote:
> On Wed, Aug 30, 2017 at 11:09:53AM +0900, Byungchul Park wrote:
> > > Signed-off-by: Peter Zijlstra (Intel)
> > > ---
> > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > > index c0331891dec1..ab3c0dc8c7ed 100644
> > > --
On Wed, Aug 30, 2017 at 11:09:53AM +0900, Byungchul Park wrote:
> On Tue, Aug 29, 2017 at 10:59:39AM +0200, Peter Zijlstra wrote:
> > Subject: lockdep: Untangle xhlock history save/restore from task
> > independence
> >
> > Where XHLOCK_{SOFT,HARD} are save/restore points in the xhlocks[] to
> >
On Tue, Aug 29, 2017 at 10:59:39AM +0200, Peter Zijlstra wrote:
> Subject: lockdep: Untangle xhlock history save/restore from task independence
>
> Where XHLOCK_{SOFT,HARD} are save/restore points in the xhlocks[] to
> ensure the temporal IRQ events don't interact with task state, the
> XHLOCK_PRO
On Wed, Aug 30, 2017 at 01:02:39AM +0900, Byungchul Park wrote:
> On Tue, Aug 29, 2017 at 5:59 PM, Peter Zijlstra wrote:
> > On Fri, Aug 25, 2017 at 10:11:14AM +0900, Byungchul Park wrote:
> >> I meant, this seems to be led from your mis-understanding of
> >> crossrelease_hist_{start, end}().
> >
On Tue, Aug 29, 2017 at 6:01 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 03:46:38PM +0900, Byungchul Park wrote:
>
>> How does a maintainer choose a very work-around method and avoid
>> problems rather than fix a root cause? I am very disappointed.
>
> Time.. we need this sorted before we
On Tue, Aug 29, 2017 at 5:59 PM, Peter Zijlstra wrote:
> On Fri, Aug 25, 2017 at 10:11:14AM +0900, Byungchul Park wrote:
>> I meant, this seems to be led from your mis-understanding of
>> crossrelease_hist_{start, end}().
>
> I have, several times now, explained why PROC is special.
I rather have
On Tue, Aug 29, 2017 at 03:46:38PM +0900, Byungchul Park wrote:
> How does a maintainer choose a very work-around method and avoid
> problems rather than fix a root cause? I am very disappointed.
Time.. we need this sorted before we push the whole lot to Linus in the
next window. Fixing the recur
On Fri, Aug 25, 2017 at 10:11:14AM +0900, Byungchul Park wrote:
> I meant, this seems to be led from your mis-understanding of
> crossrelease_hist_{start, end}().
I have, several times now, explained why PROC is special.
You seem to still think it can be used like the soft/hard-irq ones, this
is
On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote:
> The new completion/crossrelease annotations interact unfavourable with
> the extant flush_work()/flush_workqueue() annotations.
>
> The problem is that when a single work class does:
>
> wait_for_completion(&C)
>
> and
>
> co
On Thu, Aug 24, 2017 at 04:02:40PM +0200, Peter Zijlstra wrote:
> > > + if (c == XHLOCK_PROC) {
I found this now. Are you trying to invalidate it w/o checking force?
No, we _should not_ do this. It's worse than work-around code.
No reason to do this here. Please communicate with me more or unders
On Thu, Aug 24, 2017 at 04:02:40PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 24, 2017 at 11:18:40AM +0900, Byungchul Park wrote:
> > On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote:
>
> > > Also, unconditinoally switching to recursive-read here would fail to
> > > detect the actual
On Thu, Aug 24, 2017 at 11:18:40AM +0900, Byungchul Park wrote:
> On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote:
> > Also, unconditinoally switching to recursive-read here would fail to
> > detect the actual deadlock on single-threaded workqueues, which do
>
> Do you mean it's tr
On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote:
> The new completion/crossrelease annotations interact unfavourable with
> the extant flush_work()/flush_workqueue() annotations.
>
> The problem is that when a single work class does:
>
> wait_for_completion(&C)
>
> and
>
> co
The new completion/crossrelease annotations interact unfavourable with
the extant flush_work()/flush_workqueue() annotations.
The problem is that when a single work class does:
wait_for_completion(&C)
and
complete(&C)
in different executions, we'll build dependencies like:
lock_map_acqu
53 matches
Mail list logo