On (08/23/17 09:03), Byungchul Park wrote:
[..]
> > Byungchul, did you add the crosslock checks to lockdep? Can you have a look at
> > the above report? That report namely doesn't make sense to me.
>
> The report is talking about the following lockup:
>
> A work in a worker A task work on exit to user
> ------------------ ---------------------------
> mutex_lock(&bdev->bd_mutex)
> mutext_lock(&bdev->bd_mutex)
> blk_execute_rq()
> wait_for_completion_io_timeout(&A)
> complete(&A)
>
[..]
> To Peterz,
>
> Anyway I wanted to avoid lockdep reports in the case using a timeout
> interface. Do you think it's still worth reporting the kind of lockup?
> I'm ok if you do.
Byungchul, a quick question.
have you measured the performance impact? somehow my linux-next is
notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
is irritatingly slow)
`time dmesg' shows some difference, but probably that's not a good
test.
!LOCKDEP LOCKDEP LOCKDEP -CROSSRELEASE -COMPLETIONS
real 0m0.661s 0m2.290s 0m1.920s
user 0m0.010s 0m0.105s 0m0.000s
sys 0m0.636s 0m2.224s 0m1.888s
anyone else "sees"/"can confirm" the slow down?
it gets back to "usual normal" when I disable CROSSRELEASE and COMPLETIONS.
---
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b19c491cbc4e..cdc30ef81c5e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1091,8 +1091,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
- select LOCKDEP_CROSSRELEASE
- select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help
---
-ss
