Uh oh!
There was an error while loading. Please reload this page.
Add support for using a jobserver with Rayon - #56946
Conversation
rust-highfive
commented
Dec 18, 2018
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
alexcrichton
commented
Dec 18, 2018
I'm not too familiar with rayon internals, but can you describe at a high level the strategy for managing the jobserver tokens? |
Zoxc
commented
Dec 18, 2018
The strategy is to call |
alexcrichton
commented
Dec 18, 2018
As someone not familiar with rayon, can you expand on that a bit more? Acquiring and releasing a token is a pretty expensive operation and would be pretty inefficient if we did it super commonly, so is blocking in rayon something that's amortized over a long time? |
Zoxc
commented
Dec 19, 2018
There are 2 places where blocking can happen which is not related to setup/teardown:
I'd want to add that we spawn |
Zoxc
commented
Dec 19, 2018
cc @michaelwoerister too |
michaelwoerister
commented
Dec 19, 2018
Could the jobserver be made abstract to Rayon? I.e. Rayon would not directly use the jobserver crate and instead just use something with the jobserver interface to acquire and release tokens? That would be a bit more general and rustc (or any other piece of code using Rayon) could do some buffering and application-specific management of tokens (e.g. keeping tokens around a bit longer if it expects for more work to show up soon). Another approach that might be interesting: Add some way to tell Rayon the target number of active threads it should be running. It would then internally try to match this soft target by not assigning any more work to threads it wants to wind down. |
nikomatsakis
commented
Dec 19, 2018
(FYI I have this scheduled for review Thu Dec 20 at 13:00 UTC-05:00.) |
nikomatsakis
commented
Dec 20, 2018
OK, so I read this PR and the other one. @Zoxc let me summarize what I think is going on in the current PRs. I'm putting the comment here because I want to keep conversation "consolidated". I believe that the current design basically has each rayon thread acquire a token from the jobserve before it starts looking for work and release that token when it goes to sleep, right? This obviously makes a lot of sense, though I'm wondering a bit if there is some interaction with the LLVM compilation threads we want to be careful of. In particular, I believe that LLVM execution and (e.g.) trans can overlap -- this was a requirement to help us reduce peak memory usage requirements of incremental compilation, if I recall. Maybe we want to move those LLVM things into spawned rayon tasks, so that they are sharing the same basic thread-pool? (I've sort of forgotten how that system is setup, I'll have to investigate.) I would definitely prefer if the rayon core code was "agnostic" as to the specifics of the thread-pool, as @michaelwoerister suggested. Given how simple the interface is, it basically seems like we are talking about adding two callbacks -- (The PR has some other changes, e.g., adopting |
michaelwoerister
commented
Dec 21, 2018
That's basically how I imagined this work in the future. The current LLVM scheduling is rather complicated but only because codegen/trans is bound to the main thread. All of this should get a lot simpler once the |
Dylan-DPC-zz
commented
Jan 21, 2019
ping from triage @Zoxc@nikomatsakis any updates on this? |
Zoxc
commented
Jan 22, 2019
I've updated this to use the callbacks I added to Rayon. The |
rust-highfive
commented
Jan 22, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Zoxc
commented
Jan 28, 2019
Rayon threads and LLVM threads will compete for jobserver tokens. I do want to get rid of the LLVM threads once parallel queries is on by default though. |
rust-highfive
commented
Jan 28, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Zoxc
commented
Jan 29, 2019
Ping @nikomatsakis |
bors
commented
Jan 29, 2019
☔ The latest upstream changes (presumably #57948) made this pull request unmergeable. Please resolve the merge conflicts. |
bd32bc4 to
10097ccComparerust-highfive
commented
Jan 29, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
nikomatsakis
left a comment
There was a problem hiding this comment.
Seems good, but I have a few questions and nits. =)
There was a problem hiding this comment.
Maybe a doc-comment? (Also, does this struct need to be pub?)
There was a problem hiding this comment.
Similarly, I believe these can be private to the module
There was a problem hiding this comment.
This unsafe keyword feels problematic. In particular, it is asserting that GLOBAL_CLIENT is used early in the process, but it (locally, at least) has no way to know that. Basically, the clients of this module must invoke one of the public methods "early enough", right?
I feel like pub fn client should be declared unsafe, and parts of this comment moved onto it.
There was a problem hiding this comment.
I don't think any of this is related to memory safety though.
There was a problem hiding this comment.
There is no ordering dependency on when GLOBAL_PROXY is created vs GLOBAL_CLIENT, right?
There was a problem hiding this comment.
GLOBAL_PROXY requires a GLOBAL_CLIENT.
Uh oh!
There was an error while loading. Please reload this page.
rust-highfive
commented
Jan 31, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Zoxc
commented
Feb 27, 2019
@bors r=nikomatsakis |
bors
commented
Feb 27, 2019
📌 Commit a21370f8978ab051289de2bcc6f29fa2c81584af has been approved by |
bors
commented
Mar 1, 2019
☔ The latest upstream changes (presumably #58250) made this pull request unmergeable. Please resolve the merge conflicts. |
rust-highfive
commented
Mar 1, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Zoxc
commented
Mar 1, 2019
@bors r=nikomatsakis |
bors
commented
Mar 1, 2019
📌 Commit 5c78fa8 has been approved by |
bors
commented
Mar 2, 2019
Add support for using a jobserver with Rayon The Rayon changes are here: Zoxc/rayon#2 cc @alexcrichton r? @nikomatsakis
bors
commented
Mar 2, 2019
☀️ Test successful - checks-travis, status-appveyor |
michaelwoerister
commented
Mar 4, 2019
It would be great if we could have some kind of regression test for this. I don't know how to do that though (we don't have tests for the other jobserver support either). |
The Rayon changes are here: Zoxc/rayon#2
cc @alexcrichton
r? @nikomatsakis