Github user kayousterhout commented on a diff in the pull request:
https://github.com/apache/spark/pull/3779#discussion_r23332736
--- Diff:
core/src/main/scala/org/apache/spark/scheduler/TaskSetManager.scala ---
@@ -495,13 +495,39 @@ private[spark] class TaskSetManager(
* Get the level we can launch tasks according to delay scheduling,
based on current wait time.
*/
private def getAllowedLocalityLevel(curTime: Long):
TaskLocality.TaskLocality = {
- while (curTime - lastLaunchTime >= localityWaits(currentLocalityIndex)
&&
- currentLocalityIndex < myLocalityLevels.length - 1)
- {
- // Jump to the next locality level, and remove our waiting time for
the current one since
- // we don't want to count it again on the next one
- lastLaunchTime += localityWaits(currentLocalityIndex)
- currentLocalityIndex += 1
+ // remove the emptyList from pendingTasks lazily
+ def hasNonEmptyList(pendingTasks: HashMap[String, ArrayBuffer[Int]]):
Boolean = {
--- End diff --
In a big cluster, walking through all of these maps each time seems like it
could be pretty expensive, right? Why do this lazily?
Also, it occurred to me that we don't remove tasks from these lists when
they're scheduled, so this doesn't completely solve the performance issue
(because there could still be a task in one of these lists that will never be
scheduled).
This is getting fairly complex to change, and I'm wondering whether it's
worthwhile. Do you have a sense of whether these issues are a problem beyond
just the local case where people run streaming jobs that fail? And if it's
only a problem for the local case, should we just fix it in the slightly hacky
way by adding a call to revive offers to the local scheduler?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
