You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the start of the program, the DPU master thread correctly dispatches multiple requests at a time. The size of each batch largely depends on how many upper-level threads are in the ORC parser, and should be close to that number. However, towards the end of the program the upper-level threads appear to get out of sync, resulting the the DPU master thread only dispatching one request at a time.
To observe this bug add two print statements:
One in load_rank after each request's initial information is copied to the DPU
One in unload_rank after each request's ID is copied back from the DPU
Towards the start of the program, the prints will appear as a batch of "load" followed by a batch of "unload", as desired. Towards the end of the program, the prints will appear as one "load" followed by one "unload" and so on.
This needs to be fixed in hopes of achieving an efficient implementation. It may require some updates to the scheduling policy to prevent it from getting into this state, or recover if it ever gets into this state.
The text was updated successfully, but these errors were encountered:
Priority: high
At the start of the program, the DPU master thread correctly dispatches multiple requests at a time. The size of each batch largely depends on how many upper-level threads are in the ORC parser, and should be close to that number. However, towards the end of the program the upper-level threads appear to get out of sync, resulting the the DPU master thread only dispatching one request at a time.
To observe this bug add two print statements:
load_rank
after each request's initial information is copied to the DPUunload_rank
after each request's ID is copied back from the DPUTowards the start of the program, the prints will appear as a batch of "load" followed by a batch of "unload", as desired. Towards the end of the program, the prints will appear as one "load" followed by one "unload" and so on.
This needs to be fixed in hopes of achieving an efficient implementation. It may require some updates to the scheduling policy to prevent it from getting into this state, or recover if it ever gets into this state.
The text was updated successfully, but these errors were encountered: