-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Unify fs::copy and io::copy on Linux #134547
base: master
Are you sure you want to change the base?
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
It would be nice to dedupe the stat calls, but I assume that's too much of a pain? |
Unify fs::copy and io::copy on Linux Currently, `fs::copy` first tries a regular file copy (via copy_file_range) and then falls back to userspace read/write copying. We should use `io::copy` instead as it tries copy_file_range, sendfile, and splice before falling back to userspace copying. This was discovered here: SUPERCILEX/fuc#40 Perf impact: `fs::copy` will now have two additional statx calls to decide which syscall to use. I wonder if we should get rid of the statx calls and only continue down the next fallback when the relevant syscalls say the FD isn't supported.
Sorry, what do you mean by "dedupe the stat calls?" There aren't unnecessary calls—we use them to determine which syscall to use. I'm suggesting that instead of doing stat -> stat -> relevant_syscall, we can do failed_syscall -> failed_syscall -> failed_syscall -> use space copy in the worst case and go straight to copy_file_range in the fast path. So worst case it's an extra syscall but best case using any of the copy acceleration syscalls is no more than paying the stat calls. |
Ah, I had misunderstood. We can leave something like that for a future pr. |
Sounds good! I guess do we know what proportion of calls of fs/io copy are between regular files vs pipes vs sockets etc? No idea how we'd get this data lol. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (d179dd5): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary 3.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 767.128s -> 766.815s (-0.04%) |
@bors r+ |
Ok I took a look at the io::copy code and #108283 means we can't skip the stat calls for sendfile, so avoiding the stat calls for copy_file_range probably isn't worth it. Though also I lied and there are duplicate stat calls! Will fix. |
Ok, fixed. Old:
New:
|
2b4334e
to
01d69c9
Compare
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
01d69c9
to
e0a1549
Compare
Could not assign reviewer from: |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been minimized.
This comment has been minimized.
This comment was marked as off-topic.
This comment was marked as off-topic.
&mut crate::sys::kernel_copy::CachedFileMetadata(reader, reader_metadata), | ||
&mut crate::sys::kernel_copy::CachedFileMetadata(writer, writer_metadata), |
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.
The kernel_copy module is only defined for linux/android. So this would fail on some other unixes.
Currently,
fs::copy
first tries a regular file copy (via copy_file_range) and then falls back to userspace read/write copying. We should useio::copy
instead as it tries copy_file_range, sendfile, and splice before falling back to userspace copying. This was discovered here: SUPERCILEX/fuc#40Perf impact:
fs::copy
will now have two additional statx calls to decide which syscall to use. I wonder if we should get rid of the statx calls and only continue down the next fallback when the relevant syscalls say the FD isn't supported.