Don't set worker thread CPU affinity #1884
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is triggered right now by a problem with Zig build concurrency. Zig gets the number of parallel worker threads to run by inspecting its affinity. This is a great approach since it works in containers / cgroups, unlike when just inspecting /proc/cpuinfo or similar. However, zig is run as a subprocess to actonc which in turn is run as a subprocess to acton, which is an Acton program. The Acton RTS sets the thread affinity in order to pin each worker thread to a CPU core. This affinity is apparently inherited from the acton RTS worker threads to actonc and finally to zig, so it thinks it can only run on a single CPU and thus.. it's rather slow. I have been pondering the thread affinity topic in general for quite some time. I don't have any hard evidence, but I think that pinning to cores might be a premature optimization. It certainly should work better for server workloads, but for desktop workloads, which frankly we are doing more of right now (in development), I wouldn't be surprised if it works better without affinity. Anyway, turning it off isn't a biggie right now. Zig parallelism is the most important thing and no worker affinity is fine. Let's figure out how to move forward on this in the longer term. I did look into getting libuv to set affinity for the new process etc but there's nothing like that in libuv 1.x. I tried upgrading to master but then tlsuv fails. I also quickly tried to fiddle with thread affinity when I realized that we have our own pthread_setaffinity_np for macos.. and libuv has some thread affinity functions but I don't think they work on Macos. Until we sort this out, we disable thread affinity! This should speed up our cross-compilation tests in CI by quite a bit!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is triggered right now by a problem with Zig build concurrency. Zig gets the number of parallel worker threads to run by inspecting its affinity. This is a great approach since it works in containers / cgroups, unlike when just inspecting /proc/cpuinfo or similar. However, zig is run as a subprocess to actonc which in turn is run as a subprocess to acton, which is an Acton program. The Acton RTS sets the thread affinity in order to pin each worker thread to a CPU core. This affinity is apparently inherited from the acton RTS worker threads to actonc and finally to zig, so it thinks it can only run on a single CPU and thus.. it's rather slow.
I have been pondering the thread affinity topic in general for quite some time. I don't have any hard evidence, but I think that pinning to cores might be a premature optimization. It certainly should work better for server workloads, but for desktop workloads, which frankly we are doing more of right now (in development), I wouldn't be surprised if it works better without affinity.
Anyway, turning it off isn't a biggie right now. Zig parallelism is the most important thing and no worker affinity is fine. Let's figure out how to move forward on this in the longer term.
I did look into getting libuv to set affinity for the new process etc but there's nothing like that in libuv 1.x. I tried upgrading to master but then tlsuv fails.
I also quickly tried to fiddle with thread affinity when I realized that we have our own pthread_setaffinity_np for macos.. and libuv has some thread affinity functions but I don't think they work on Macos. Until we sort this out, we disable thread affinity!
This should speed up our cross-compilation tests in CI by quite a bit!
Fixes #1880