Page MenuHomeFreeBSD

add recommendation for using a large "len" argument
ClosedPublic

Authored by rmacklem on Jan 2 2021, 11:04 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 6 2024, 9:59 AM
Unknown Object (File)
Oct 3 2024, 10:26 AM
Unknown Object (File)
Oct 1 2024, 8:26 AM
Unknown Object (File)
Sep 30 2024, 5:45 AM
Unknown Object (File)
Sep 30 2024, 5:45 AM
Unknown Object (File)
Sep 30 2024, 5:45 AM
Unknown Object (File)
Sep 30 2024, 4:52 AM
Unknown Object (File)
Sep 30 2024, 4:42 AM
Subscribers
None

Details

Summary

PR#252358 reported a serious performance problem w.r.t.
cp(1) when copying large non-sparse files.
This problem appears to have been caused by cp(1)
calling copy_file_range(2) with a small "len" argument.

This patch adds a recommendation to use a large "len"
value where possible, for performance reasons.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

rmacklem created this revision.
asomers requested changes to this revision.Jan 2 2021, 11:18 PM
asomers added inline comments.
lib/libc/sys/copy_file_range.2
144

I think this belongs in the DESCRIPTION section, not RETURN VALUES.

147

Why SSIZE_MAX? Since len is defined as a size_t, shouldn't the limit be SIZE_MAX ?

149

I think this qualifies as TMI. I might phrase it as "For best performance, call copy_file_range with the largest len value possible. It is interruptible on most file systems, so there is no penalty for using very large len values, even SSIZE_MAX."

This revision now requires changes to proceed.Jan 2 2021, 11:18 PM

Update patch as recommended by asomers@.

Handled inline comments.

lib/libc/sys/copy_file_range.2
147

Because it returns ssize_t.
I didn't think that needed to be stated here,
but if you think it should be, I can add a
sentence.

asomers added inline comments.
lib/libc/sys/copy_file_range.2
147

Ahh, that makes sense.

This revision is now accepted and ready to land.Jan 3 2021, 12:30 AM