Skip to main content
Unix & Linux

Return to Answer

Minor formatting improvement
Source Link
AdminBee
AdminBee
  • 23.6k
  • 25
  • 56
  • 78

The problem, and solution, have now been found. (ItIt is a bug in the LLVM code.)

"It's a bug in the atfork() handler on Unix systems + logic in reinitializing the child process. The current library incorrectly sets the child process' affinity to compact, which roughly translates to "pin consecutive threads to consecutive cores", even when the user hasn't set KMP_AFFINITY to anything. So every child process was pinned to the first core instead of the entire system."

From https://github.com/llvm/llvm-project/issues/91098GitHub issues:

It's a bug in the atfork() handler on Unix systems + logic in reinitializing the child process. The current library incorrectly sets the child process' affinity to compact, which roughly translates to "pin consecutive threads to consecutive cores", even when the user hasn't set KMP_AFFINITY to anything. So every child process was pinned to the first core instead of the entire system.

The problem, and solution, have now been found. (It is a bug in the LLVM code.)

"It's a bug in the atfork() handler on Unix systems + logic in reinitializing the child process. The current library incorrectly sets the child process' affinity to compact, which roughly translates to "pin consecutive threads to consecutive cores", even when the user hasn't set KMP_AFFINITY to anything. So every child process was pinned to the first core instead of the entire system."

https://github.com/llvm/llvm-project/issues/91098

The problem, and solution, have now been found. It is a bug in the LLVM code.

From GitHub issues:

It's a bug in the atfork() handler on Unix systems + logic in reinitializing the child process. The current library incorrectly sets the child process' affinity to compact, which roughly translates to "pin consecutive threads to consecutive cores", even when the user hasn't set KMP_AFFINITY to anything. So every child process was pinned to the first core instead of the entire system.

Source Link
Adam Ellis
Adam Ellis
  • 31
  • 3

The problem, and solution, have now been found. (It is a bug in the LLVM code.)

"It's a bug in the atfork() handler on Unix systems + logic in reinitializing the child process. The current library incorrectly sets the child process' affinity to compact, which roughly translates to "pin consecutive threads to consecutive cores", even when the user hasn't set KMP_AFFINITY to anything. So every child process was pinned to the first core instead of the entire system."

https://github.com/llvm/llvm-project/issues/91098