-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
fs: support io_uring with tokio::fs::read
#7696
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
f4c97c2 to
7e73f17
Compare
tokio/src/fs/read.rs
Outdated
| let mut offset = 0; | ||
|
|
||
| while size_read < size { | ||
| let left_to_read = (size - size_read) as u32; |
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.
| let left_to_read = (size - size_read) as u32; | |
| let left_to_read = u32::try_from(size - size_read).unwrap_or(u32::MAX); |
To properly support files bigger than 4GB.
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.
max read size at a time is u32::MAX, we read the rest in other next iterations
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.
In the future, if we know we're reading more than u32::MAX then we can batch 2 read requests to avoid extra syscalls
6237a4c to
636cfb8
Compare
ADD-SP
left a comment
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.
This looks complicated, I will review it incrementally.
6e0abae to
8120700
Compare
mox692
left a comment
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 haven't checked all of the details in read_uring.rs, but left some comments I've noticed so far.
e6c6ce7 to
b9c3885
Compare
d219de6 to
a90b5c7
Compare
e1909d0 to
dfe83fe
Compare
2c205e7 to
96c977e
Compare
Reading 64 MB chunks at a time and keeping the kernel busy surpases
std::fs::read time with unoptimized io_uring one being 1.12% fast
Fix tests fail on allocation failure
Doc fix and fix double subtraction of offset
Fix typos and use assert the stopped task's first poll
Add comments and panic on failed u32 conversion
Check the EOF internally in the `op_read` function
Fix test with noop waker
995185b to
fb23b82
Compare
ADD-SP
left a comment
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.
Thanks!
Motivation
We slowly use io uring everywhere here I made the simple change of supporting
fs::readhowever it might not be as simple. Let me know if the unsafe I used is correct or not.We currently use the blocking
std::fs::MetaDatato obtain file size for buffer capacity and extend the length of the vector according to the bytes read in the CQE. This implementation sounds good on paper to me.Later we should implement an internal statx helper, in this PR or a seperate PR to make our uring implementation less painful to use. As this pr failed #7616
Lets put statx helper in different PR to avoid merging an inefficient read implementation given io uring is about being more efficient in file IO
Solution
Continue adopting io uring
strace on a
tokio::fs::readafter this change