-
Notifications
You must be signed in to change notification settings - Fork 3k
[scheduler] Another task-stealing optimization #9984
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
Conversation
CT Test Results 3 files 135 suites 49m 11s ⏱️ Results for commit 09c6a67. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
|
I appear to have missed some failed assert in debug builds, I'm looking into it. |
|
The I added a new commit "Track waiting schedulers" removing the assert that hit and added another way of keeping track of waiting schedulers. It is not used everywhere where it could be used, but I think that the legacy configurations that this is the case for will behave more as before by not changing them. Please remove the meta internal stuff like the following from the commit messages: |
If we steal exactly one task, then we directly execute it, and it never ends up in our runqueue. So it is wrong to update the flag telling everyone that we have work they can steal. If we steal more than one task, then we will call erts_add_runq_len, which will take care of calling erts_non_empty_runq for us.
There are two benefits: - Being FIFO rather than LIFO, we are much more likely to find the runqueue uncontended on the second pass (since it is a runqueue that was found contended a lot earlier) - We can now do several passes, rather than defaulting to a blocking call to lock on the second pass. There was just one small issue: the implementation of equeues did not support passing them across function boundaries, since it used a preprocesor macro to find the default queue (when trying to grow the queue). I fixed that by adding a field to the queue itself.
65348b0 to
09c6a67
Compare
|
Thanks for fixing the assertion, and sorry for the messed-up commit messages. |
The main win here is the third commit.
It is a followup to #9594, and was tested in prod on multiple kinds of machines and multiple services.
We observed some small but significant wins in scheduler utilisation, including at peak load which was the weak point of the previous batch of optimisations.
cc @tomas-abrahamsson since you saw large wins from the previous batch of scheduler enhancements.