Skip to content

Conversation

@gjoseph92
Copy link
Collaborator

Minor readability and performance improvement that avoids trying to send a queued task to processing when a slot opens on a non-running worker.

This doesn't affect correctness. Currently, a task will be recommended to processing and we'll look for a worker for it. Since the worker isn't running, we won't pick it, and the task will stay in queued. With this PR, we simply save ourselves doing the search when we know it won't be fruitful.

I haven't come up with a nice way to test this (since it shouldn't affect behavior and the performance difference will be minuscule anyway.) I could look at the scheduler transition logs and assert there's no extra queued->processing->queued transition in this case, but that feels a bit nitpicky for a case that isn't very important.

  • Passes pre-commit run --all-files

@gjoseph92 gjoseph92 requested a review from fjetter October 25, 2022 16:15
@gjoseph92 gjoseph92 self-assigned this Oct 25, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Oct 25, 2022

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

       15 files  ±  0         15 suites  ±0   6h 52m 44s ⏱️ + 18m 17s
  3 166 tests +10    3 080 ✔️ +  16    84 💤  -   2  2  -   4 
23 424 runs  +75  22 516 ✔️ +104  904 💤  - 12  4  - 17 

For more details on these failures, see this check.

Results for commit 29cf615. ± Comparison against base commit 0983731.

♻️ This comment has been updated with latest results.

if state.queued and not _worker_full(ws, state.WORKER_SATURATION):
if (
state.queued
and ws.status == Status.running
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true right now but if we ever had more Status types, of which some might actually be runnable, this could cause a deadlock, couldn't it?
I know this is pretty hypothetical but my point is that we do not change the behavior but encode more assumptions in the code for a perf improvement you call yourself minuscule (and rare)

I don't mean to block this if you consider it truly better readable but I'm a soft -0

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like a pretty far-fetched problem. There are already 18 instances of == Status.running in scheduler.py.

I've added a test. This is still not a big deal, it's just a small tidying up.

@gjoseph92 gjoseph92 mentioned this pull request Oct 28, 2022
11 tasks
@gjoseph92
Copy link
Collaborator Author

The primary change here was incorporated in #7224

@gjoseph92 gjoseph92 closed this Oct 31, 2022
@gjoseph92 gjoseph92 deleted the exit-processing-submit-queued-only-if-running branch November 10, 2022 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants