Remove forced copying in local load_bytes_with#9793
Merged
stuhood merged 3 commits intoMay 16, 2020
Conversation
[ci skip-jvm-tests]
…ng optional. [ci skip-jvm-tests]
…in memory to the chunk size. [ci skip-jvm-tests]
stuhood
requested review from
gshuflin,
illicitonion,
jsirois and
tdyas
and removed request for
gshuflin
Contributor
illicitonion
left a comment
illicitonion
left a comment
There was a problem hiding this comment.
Looks great, thanks!
Will post a few more thoughts on #9395, too :)
| .to_boxed(), | ||
| let resource_name = resource_name.clone(); | ||
| let store = store.clone(); | ||
| let f = f.clone(); |
Member
Author
There was a problem hiding this comment.
with_byte_stream_client is executing a loop calling a closure that returns a future. The future that is created each time the closure is called takes ownership of the value, so we need the clone.
I think that I could fiddle with the lifetime parameters to declare that the closure returns a future with a lifetime tied to the inputs...? But this is green, so gonna let it slide...
illicitonion
approved these changes
May 16, 2020
Eric-Arellano
added a commit
that referenced
this pull request
Apr 21, 2021
Closes #11908. As described there, `ensure_remote_has_recursive()` was blocking due to its call to `executor.block_on()`. This was introduced in #9793, which reasoned that only the spawned thread would get blocked, which would be safe - but it turns out that this blocking stops Pants from doing anything else. This was not introduced due to the upgrade from Tokio 0.2 to 1.x, and it's plausible this never worked as intended with remote caching, given that remote caching was not available in May 2020. Fundamentally, the issue makes sense. Reading from LMDB Store must be synchronous to be safe, which we correctly expressed, e.g. via using `Executor.spawn_blocking()`. We tried to minimize memory consumption by allowing for a callback to access a reference/slice of the bytes, rather than cloning it. However, we desire for the remote code to be async, e.g. so that it can finish in the background a la #11479. If it's async, it fundamentally would not be able to use a reference because that reference may no longer be valid - we need to clone the data to fully own it. While cloning the bytes will result in more memory consumption, it is imperative that remote caching fails gracefully. The increase in memory consumption is less offensive than #11908, i.e. that slowness in remote cache writes can slow down and even hang Pants.
Eric-Arellano
added a commit
to Eric-Arellano/pants
that referenced
this pull request
Apr 21, 2021
Closes pantsbuild#11908. As described there, `ensure_remote_has_recursive()` was blocking due to its call to `executor.block_on()`. This was introduced in pantsbuild#9793, which reasoned that only the spawned thread would get blocked, which would be safe - but it turns out that this blocking stops Pants from doing anything else. This was not introduced due to the upgrade from Tokio 0.2 to 1.x, and it's plausible this never worked as intended with remote caching, given that remote caching was not available in May 2020. Fundamentally, the issue makes sense. Reading from LMDB Store must be synchronous to be safe, which we correctly expressed, e.g. via using `Executor.spawn_blocking()`. We tried to minimize memory consumption by allowing for a callback to access a reference/slice of the bytes, rather than cloning it. However, we desire for the remote code to be async, e.g. so that it can finish in the background a la pantsbuild#11479. If it's async, it fundamentally would not be able to use a reference because that reference may no longer be valid - we need to clone the data to fully own it. While cloning the bytes will result in more memory consumption, it is imperative that remote caching fails gracefully. The increase in memory consumption is less offensive than pantsbuild#11908, i.e. that slowness in remote cache writes can slow down and even hang Pants. # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem
The LMDB API allows for direct references into its storage, which will always be MMAP'ed. But because it has a blocking API, we interact with it on threads that have been spawned for that purpose.
To allow for interacting with the database in a way that avoids copying data into userspace, the
load_bytes_withmethod takes a function that will be called on the blocking thread with a reference directly to that memory. This allows for minimizing copies of data, and avoiding holding full copies of database entries in memory.But at some point a while back (before async/await made dealing with references easy again),
load_bytes_withstarted passing aBytesinstance to its callback. And constructing aBytesinstance with anything other than a static memory reference (which this isn't) requires copying into theBytesinstance to give it ownership. This meant that we weren't actually taking advantage of the odd shape ofload_bytes_with.Solution
Switch the local
load_bytes_withback to providing a reference into the database's owned memory, and document the reason for its shape. In separate commits, port theserversetcrate and code that touches it to async/await. Finally, adjust the remotestore_bytesto accept a reference to avoid potential copies there as well.Result
Less memory usage, and less copying of data. In particular: cases that read from the local database in order to copy elsewhere (such as
materialize_directory,ensure_remote_has_recursive, and BRFSread) will now copy data directly out of the database and into the destination.ensure_remote_has_recursiveshould now hold onto only one chunk's worth of data at a time per file it is uploading, which might be sufficient to fix #9395 (although the other changes mentioned there will likely still be useful).