Skip to content
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

CheckpointServer: start in disallowed state + tests #90

Merged
merged 1 commit into from
Jan 30, 2025

Conversation

d4l3k
Copy link
Member

@d4l3k d4l3k commented Jan 30, 2025

This fixes a regression that was introduced in #81.

We need to start checkpoint server in disallowed state so new requests coming in will block until the first time we call send_checkpoint. This prevents requesters erroring out on the first request since the server only has step -1.

This also added a timeout on acquiring the lock in the server thread (since we already timeout the socket) so don't want to get stuck there.

Test plan:

Added disallow_checkpoint call in torchtitan

Added unit tests for this behavior

pytest torchft/checkpointing_test.py

@d4l3k d4l3k requested review from fegin and H-Huang January 30, 2025 17:01
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Meta Open Source bot. label Jan 30, 2025
Copy link
Member

@H-Huang H-Huang left a comment

Choose a reason for hiding this comment

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

Looks good!

@@ -117,7 +141,9 @@ def do_GET(self):
# validate socket timeout is actually set
assert self.connection.gettimeout() == self.timeout

Copy link
Member

Choose a reason for hiding this comment

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

Would it make sense to add an assert to check self._step == -1 (or maybe initialize step to None and check that) to fail quickly rather than to wait and timeout?

Copy link
Member Author

Choose a reason for hiding this comment

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

We actually are doing that which is the issue. Down below we check if self._step == the requested step

We end up with a race condition between send_checkpoint and the remote worker requesting the checkpoint which causes the requester to get an error due to mismatched step

This lock allows us to have some tolerance when requesting a checkpoint. We could busy loop/retry on caller side but the lock makes the code simpler and a bit more efficient

@d4l3k d4l3k merged commit 68e1d28 into main Jan 30, 2025
6 checks passed
@d4l3k d4l3k deleted the d4l3k/checkpoint_regression branch January 30, 2025 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Meta Open Source bot.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants