-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
performance regression and occasionnal dead-lock when linking with llvm 3.9 #36905
Comments
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) |
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 Here is the gdb backtrace for all threads.
|
I assume the performance problem to be related to OpenBSD pthread implementation. |
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? |
From the stacktrace it looks like a deadlock in Moreover the One possible execution trace (corresponding to above stracktrace) would be more
Deadlock, because T1 waits for For potential workaround, take a look at |
I am currently testing it. Thanks. |
The workaround works well. Thanks for your help ! |
I experiment some problems with rustc 1.12.0 (under OpenBSD):
There are two kind of problems:
xxx has been running for over 60 seconds
messages in make checkthrslee
state.For the performance problem, by tracing the syscalls I saw lot of
__thrsleep()
,__thrwakeup()
andsched_yield()
dance: the process makes high usage of thread-syscalls, and it slows down.Some stats for 1 second, I have 16314 syscalls:
For this second, by thread:
I am unsure about the way to better describe the problem or reduce it.
The text was updated successfully, but these errors were encountered: