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

Add lock in prefill and generate to prevent starvation #126

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

FanhaiLu1
Copy link
Collaborator

Current issues

In current jetstream orchestrator, decode can start after prefill start but before prefill finished. Jax multiple controller run mix of prefill and decode step at certain time, this will cause deadlock and hang the jax program (suppose there are n chips, prefill wait n -1 prefill finished, decode wait another n -1 decode finish, but neither of them can reach all n finished).

Fix

Add lock in prefill and generate to make sure the two function are executed in sequential.

Long term fix

Refactor jetstream and let orchestrator handle the function call correctly in multiple controller jax.

@FanhaiLu1 FanhaiLu1 requested review from qihqi and wang2yn84 June 13, 2024 21:42
Copy link
Collaborator

@wang2yn84 wang2yn84 left a comment

Choose a reason for hiding this comment

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

Do you need to lock insert too?

@FanhaiLu1
Copy link
Collaborator Author

FanhaiLu1 commented Jun 13, 2024

Do you need to lock insert too?

Based on practice (my tests ), we don't need do a lock for insert. The insert resource in minimal (no compute, only a slot pre allocated) resource, it doesn't block prefill or vice visa.

@@ -38,6 +39,8 @@ def __init__(
self.batch_size = batch_size
self.is_disaggregated = is_disaggregated
self.pod_slice_name = pod_slice_name
if not self.is_disaggregated:
self._lock = threading.Lock()
Copy link
Collaborator

Choose a reason for hiding this comment

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

lets use RLock. For lock if the thread already have the lock and it try to lock again it will deadlock

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Use lock (without R) should be the right way. The jetstream may have the issue before (same thread call prefill or decode concurrently), there is no recursion in prefill or decode code.

If a thread call the both prefill and decode or itself method multiple time without unlock, then there is a bug on jetstream.

@FanhaiLu1 FanhaiLu1 merged commit dc90aea into AI-Hypercomputer:main Jun 14, 2024
4 checks passed
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.

3 participants