use mmap for checksum of larger RPMs #296
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By using mmap() rather than read()ing into a buffer, we can avoid the kernel having to copy pages around, and it's also easy to hint that we are going to access the whole file. This alone, on a m5n.16xlarge EC2 instance doing a reposync of the Amazon Linux 2023 x86-64 repository cuts around 2.5 seconds from the duration of a reposync, as well as about .5 seconds off system time. When combined with the avoiding libc buffered IO patch, we gain an extra 0.5 seconds of elapsed time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By using mmap() rather than read()ing into a buffer, we can avoid the kernel having to copy pages around, and it's also easy to hint that we are going to access the whole file.
This alone, on a m5n.16xlarge EC2 instance doing a reposync of the Amazon Linux 2023 x86-64 repository cuts around 2.5 seconds from the duration of a reposync, as well as about .5 seconds off system time.
When combined with the avoiding libc buffered IO patch, we gain an extra 0.5 seconds of elapsed time.
For reference, my benchmarking has been done on a
m5n.16xlargeEC2 instance to the in-region S3 buckets as well as to the CDN repositories. That instance type has 256GB memory, a 75Gbit network connection, and is a 64 core Cascade Lake system. The root volume is a 256GB gp3 EBS volume with 500MB/sec of IO and 3000 IOPs.The background of this is that a lot of EC2 instances don't live that long (relatively speaking), and never install RPMs except on launch - so all the time-to-install RPMs is time spent scaling up a system that could be better served by running the customer workload.
Goes well when paired with #294 and #295