To answer your question I did on my Linux:
gdb --args julia -e "exit()"
(gdb) b pthread_create
Breakpoint 1, 0x00007ffff77fb560 in pthread_create@@GLIBC_2.2.5 ()
from /usr/bin/../lib/libpthread.so.0
and then looked at the backtraces of all the location were we are creating threads during startup.
- 1x
pthread_create
insrc/signals-unix.c
- 7x
pthread_ctreate
inblas_thread_init () from /usr/bin/../lib/julia/libopenblas64_.so
Starting Julia with -t 4
adds another three calls in jl_start_threads
.
Setting OPENBLAS_NUM_THREADS=1
as an environment removes the additional threads created by OpenBLAS. Leaving you with the main thread, the signal thread and the -t N
N-1 worker threads.
I suspect that all of the thread pinning libraries like numactl
treats all of them equally, which is why you see two Julia threads being pinned to the same process, since OpenBLAS in the mix oversubscribes the cores. There was some initial thinking about having OpenBLAS use the Julia thread pool partr thread support for openblas · Issue #32786 · JuliaLang/julia · GitHub, but that hasn’t been implemented yet.