-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-32878][CORE] Avoid scheduling TaskSetManager which has no pending tasks #29750
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
|
@tgravescs @jiangxb1987 @cloud-fan Any idea on this? |
tgravescs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely seems like a good thing in general, I was a little worried about other side affects that happen in the scheduling loop but the only one I saw was with locality which doesn't matter since no pending tasks so I think its ok.
|
Test build #128660 has finished for PR 29750 at commit
|
jiangxb1987
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
dongjoon-hyun
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, LGTM. It seems that @mridulm 's comment is the last one we need to do.
|
Thanks all! I've addressed the comment. |
|
Merged to master for Apache Spark 3.1.0 on December 2020. |
|
Thank you, @Ngone51 and all! |
|
Test build #128689 has finished for PR 29750 at commit
|
What changes were proposed in this pull request?
This PR proposes to avoid scheduling the (non-zombie) TaskSetManager which has no pending tasks.
Why are the changes needed?
Currently, Spark always tries to schedule a (non-zombie) TaskSetManager even if it has no pending tasks. This causes notable problems for the barrier TaskSetManager: 1.
calculateAvailableSlotscan be called for multiple times for a launched barrier TaskSetManager; 2. user would see "Skip current round of resource offers for barrier stage" log message fora launched barrier TaskSetManager all the time until the barrier TaskSetManager finishes, which is quite confused.
Besides, scheduling a TaskSetManager always involves many function invocations even if there're no pending tasks.
Therefore, I think we can skip those un-schedulable TasksetManagers to avoid the potential overhead.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass existing tests.