Skip to content

Conversation

dannycjones
Copy link
Contributor

Mountpoint's S3 client has a backpressure mechanism to controlling how much data to fetch. This change updates the way Mountpoint's prefetcher signals to Mountpoint's S3 client (using the AWS CRT internally) to fetch more data ahead of where a consuming application is reading to accelerate throughput.

Before this change, Mountpoint would wait for 50% of the existing window to be consumed. For example with a window of 2GiB, 1GiB must be read by the kernel before Mountpoint would inform the S3 client to fetch more data up to 2GiB ahead of the current position.

After this change, Mountpoint now sends this signal with every read by the kernel. For example, a 128KiB read by the Kernel to fill a page in the page cache will result in the CRT being updated to be 2GiB ahead of the end offset of the 128KiB read, where the readahead window has a size of 2GiB.

We observe improved throughput for single file handle sequential reading with this approach. For random reading and for multiple file handle reading, we don't see an observable change in throughput. We expect this may be a prerequisite for driving higher throughput with multiple file handles, with this potentially being one bottleneck among others.

Does this change impact existing behavior?

This improves the way Mountpoint signals progress to its S3 client. We expect improvements in throughput, but the end-user behavior hasn't changed in a meaningful way.

Does this change need a changelog entry? Does it require a version change?

A changelog entry has been added to note the change in algorithm, alongside ensuring a minor version bump. This is added to communicate the change, in case any issue is raised around the change in behavior. However, we do not expect any regressions given the benchmarking performed.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).

Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
…inearly with reads

Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
@dannycjones dannycjones requested review from mansi153 and sahityadg June 4, 2025 10:04
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones temporarily deployed to PR integration tests June 4, 2025 10:04 — with GitHub Actions Inactive
@dannycjones dannycjones added the performance PRs to run benchmarks on label Jun 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance PRs to run benchmarks on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant