-
Notifications
You must be signed in to change notification settings - Fork 101
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
TL/UCP: Allow self copy in allgather using network loopback #1021
base: master
Are you sure you want to change the base?
Conversation
Can one of the admins verify this patch? |
5e852a7
to
7e6c55d
Compare
d13b885
to
b3c2e80
Compare
ok to test |
482006f
to
eecdebf
Compare
1d88c9b
to
820794d
Compare
@Sergei-Lebedev why do we have to keep approving runs when force pushing?? Seems an outlier here |
32b3ccd
to
b1c875b
Compare
2dc74f3
to
a2c5fee
Compare
step = task->tagged.send_posted; | ||
int iter = use_cuda ? tsize - 1 : tsize; //when using loopback tagged.send_posted has 1 more which will cause non-complete ring algorithm | ||
while (task->tagged.send_posted < iter) { | ||
step = use_cuda ? task->tagged.send_posted : task->tagged.send_posted - 1; //when using loopback tagged.send_posted has 1 more which will cause wrong calculation of send/recv |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since loopback affects algorithm flow I would rather consider checking loopback copy result somehow differently, maybe add custom callback for ucp recv completion
a2c5fee
to
5940100
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! It Looks good, I left a bunch of comments mainly on codestyle.
However, please add tests for that feature.
Also please note from the CI:
Commit title is too long: 59
Bad commit title: 'TL/UCP: Allow self copy in allgather using network loopback'
|
||
if (UCC_INPROGRESS == ucc_tl_ucp_test(task)) { | ||
return; | ||
} | ||
sendto = ucc_ep_map_eval(task->subset.map, (trank + 1) % tsize); | ||
recvfrom = ucc_ep_map_eval(task->subset.map, (trank - 1 + tsize) % tsize); | ||
|
||
while (task->tagged.send_posted < tsize - 1) { | ||
step = task->tagged.send_posted; | ||
int iter = use_loopback ? tsize : tsize - 1; //when using loopback tagged.send_posted has 1 more which will cause non-complete ring algorithm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
declaration of variable goes to the beginning of the function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure to understand the comment. What do you mean by "will cause non-complete ring algorithm"?
Can you use a more explicit name than iter
for that variable?
@yaeliyac btw, for knomial inplace, we don't expect any change, right? Do we have an explanation for the degradation in the graph? |
5940100
to
6cb2e0e
Compare
6cb2e0e
to
5ba0039
Compare
What
Add option for self copy loopback in out of place start for allgather algorithms: knomial, ring, neighbor, sparbit
Why ?
When using UCC plugin for NCCL, using cuda_memcpy might cause deadlock
How ?
Add UCC_TL_UCP_ALLGATHER_USE_LOOPBACK flag to control this
Tested on ISRAEL-1 with multiple test cases - showed good results and same performance with and without loopback