Closed
Description
I experiment some problems with rustc 1.12.0 (under OpenBSD):
- when builded with system LLVM 3.8.1 : seems ok
- when builded with system LLVM 3.9.0 (with additionnal patch rL281650 for ICE: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `!contains(New, this) && "this->replaceAllUsesWith(expr(this)) is NOT valid!"' failed. #36474) : problems
- when builded with embedded LLVM: still problems
There are two kind of problems:
- performance regression from stable to stable : I saw lot of
xxx has been running for over 60 seconds
messages in make check - occasionnally rustc compiler dead-lock: all threads are in
thrslee
state.
For the performance problem, by tracing the syscalls I saw lot of __thrsleep()
, __thrwakeup()
and sched_yield()
dance: the process makes high usage of thread-syscalls, and it slows down.
Some stats for 1 second, I have 16314 syscalls:
- 7344 __thrwakeup
- 7343 __thrsleep
- 1605 sched_yield
- 11 mmap
- 4 write
- 4 mquery
- 2 munmap
- 1 fstat
For this second, by thread:
- thread 1031567:
- 1850 __thrsleep
- 1850 __thrwakeup
- 443 sched_yield
- thread 1048099
- 1848 __thrsleep
- 1848 __thrwakeup
- 298 sched_yield
- thread 1056179:
- 1844 __thrsleep
- 1844 __thrwakeup
- 483 sched_yield
- 4 write
- 3 mmap
- 2 mquery
- 1 munmap
- 1 fstat
- thread 1065035:
- 1801 __thrsleep
- 1802 __thrwakeup
- 381 sched_yield
- 8 mmap
- 2 mquery
- 1 munmap
I am unsure about the way to better describe the problem or reduce it.
Activity
nagisa commentedon Oct 2, 2016
Looks a lot like some thread synchronisation (mutexes?). Does OpenBSD pthread mutex make a syscall each time the mutex is locked and unlocked?
That’s amusing. Could you get a backtrace for all the threads when this happens? (You can cause a coredump with SIGQUIT, after setting ulimit to allow coredumps. Opening the coredump with gdb should then allow you to recover the backtrace)
semarie commentedon Oct 3, 2016
Under OpenBSD, threads synchronisation primitives relies on syscalls. I am unsure for all the details (when a syscall is called / when it is unneed). But
__thrwakeup
,__thrsleep
andsched_yield
are used by pthread.Here is the gdb backtrace for all threads.
semarie commentedon Oct 3, 2016
I assume the performance problem to be related to OpenBSD pthread implementation.
The dead-lock could be something else.
alexcrichton commentedon Oct 3, 2016
Interesting, sure does look like a lot of mutexes going around! I wonder if LLVM 3.9 tweaked something to grab a lock where it didn't before, and now these problems are happening?
semarie commentedon Oct 4, 2016
I am currently testing it. Thanks.
semarie commentedon Oct 4, 2016
The workaround works well. Thanks for your help !