-
Notifications
You must be signed in to change notification settings - Fork 797
[SYCL] Wait before deleting a stream buffer #2646
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
Conversation
904462f
to
1f55f00
Compare
Currently streamed data is printed in a host task. Host task has a corresponding empty task which is a leaf command for a stream buffer. Since stream buffer is not a leaf for a kernel it doesn't block the kernel from being cleaned up after completion. During this cleanup process stream buffer is deleted, as a result scheduler does a blocking enqueue of the empty task. Problem is that this empty task has a blocked status (blocked by host task). This results in exception saying that we try to wait for a blocked command. It is not clear if this use case is invalid or there is a bug in the scheduler. Explicitly waiting for a host task before stream buffer deletion is correct for sure and resolves this problem.
b2ed312
to
16f624f
Compare
/summary:run |
@@ -67,7 +67,7 @@ void stream_impl::flush() { | |||
// finishes execution. | |||
auto Q = detail::createSyclObjFromImpl<queue>( | |||
cl::sycl::detail::Scheduler::getInstance().getDefaultHostQueue()); | |||
Q.submit([&](handler &cgh) { | |||
auto Event = Q.submit([&](handler &cgh) { |
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.
During this cleanup process stream buffer is deleted, as a result scheduler does a blocking enqueue of the empty task.
As far as I understand the cleanup may happen right after the kernel is executed while the printing host-task isn't executed yet. Is that correct?
Hence, I wonder if it is possible that stream_impl::flush
is invoked after kernel's execution?
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'm not sure it's a bug, let's discuss offline.
Refactor KNOWN_FAILURE implementation to avoid repeated logic.
Refactor KNOWN_FAILURE implementation to avoid repeated logic.
Currently streamed data is printed in a host task. Host task has a corresponding empty task which is a leaf command for a stream buffer. Since stream buffer is not a leaf for a kernel it doesn't block the kernel from being cleaned up after completion. During this cleanup process stream buffer is deleted, as a result scheduler does a blocking enqueue of the empty task. Problem is that this empty task has a blocked status (blocked by host task). This results in exception saying that we try to wait for a blocked command. It is not clear if this use case is invalid or there is a bug in the scheduler.
Explicitly waiting for a host task before stream buffer deletion is correct for sure and resolves this problem.