-
Notifications
You must be signed in to change notification settings - Fork 135
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
Fix memory ordering in needs_wake #281
Conversation
A memory fence is required to ensure the decision of the kernel needing waking is consistent between user-space and kernel. The kernel must not go to sleep without us reliably observing the wake flag, respectively it must see updates to the submission head if our load does not contain updated wake flag. The fence is paired with one in the kernel which ensures that one of the two stores is observed by the respective load of the other party.
There is no other state that is acquired. The barrier which the library or callers are required to ensure provides the necessary synchronization with regards to kernel state.
Like I mentioned in the linked issue, I think the best place to put the |
I do disagree with that, the library exposes access to the |
I should put the fix in the right location though and add a barrier to the |
The high-level interface in the I honestly don't know why |
Sure, the fix on I believe I'll ultimately leave this to maintainer's approach to the library interface. Commits are structure to include sufficient relevant documentation for each individual change (where it concerns public vs. private API). |
Thank you! Anyway I agree align to liburing. |
A memory fence is required to ensure the decision of the kernel needing waking is consistent between user-space and kernel. The kernel must not go to sleep without us reliably observing the wake flag, respectively it must see updates to the submission head if our load does not contain updated wake flag. The fence is paired with one in the kernel which ensures that one of the two stores is observed by the respective load of the other party.
Fix: #197