Skip to content
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

Add caching CommandRunner wrapper #7911

Conversation

illicitonion
Copy link
Contributor

@illicitonion illicitonion commented Jun 20, 2019

This allows any CommandRunner to be wrapped and transparently cache
all process executions it performs.

@illicitonion
Copy link
Contributor Author

Bottom 3 commits are dependent PRs (#7908, #7909, #7910), top commit has the meat.

Top commit has two things mixed into it:

  1. Move some code in remote.rs to live outside of the remote::CommandRunner struct, and change error types to by String instead of ExecutionError::Fatal(String) (and otherwise not make any changes), so it can be re-used.
  2. Add cache.rs which re-uses that code.

@illicitonion illicitonion requested a review from gshuflin June 21, 2019 18:49
Copy link
Member

@stuhood stuhood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! One blocker I think, but otherwise looks good.


impl CommandRunner {
fn digest(&self, req: &ExecuteProcessRequest) -> Result<Digest, String> {
// TODO: Parameterise options
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. Passing ~all of these looks like a blocker for landing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

directory
});
let process_execution_store = self.process_execution_store.clone();
self
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably use a different default_lease_until_secs_since_epoch value than everything else in the store. Best as a followup though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a TODO. Also added a TODO to ever GC this store.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... Why wouldn't this be affected by the existing GC...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently garbage collection is exposed by Store (which is a layer on top of ShardedLmdb), and this uses a separate ShardedLmdb. It's easy to add GCing, but this currently isn't done.

.join(
self
.file_store
.store_file_bytes(result.stderr.clone(), true),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we fail to get any of these, we should probably just treat it as a cache miss rather than a failure (possibly with debug or trace logging), because I can definitely imagine some of the dependency data expiring out here a little bit out of order with the actual cache entry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@illicitonion illicitonion force-pushed the dwagnerhall/local-process-execution-cache/cache branch from 7c45fb2 to 99ab171 Compare June 21, 2019 23:46
@illicitonion illicitonion force-pushed the dwagnerhall/local-process-execution-cache/cache branch from 99ab171 to e42f5b2 Compare July 10, 2019 16:29
@illicitonion
Copy link
Contributor Author

Now depends on #8035 then should be good to go :)

Copy link
Member

@stuhood stuhood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

directory
});
let process_execution_store = self.process_execution_store.clone();
self
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... Why wouldn't this be affected by the existing GC...?

stdout_digest, error
)
})
.and_then(move |maybe_value| {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this method and branch return an Option instead so that this case can be handled differently by the caller for the cache vs other cases? Ditto the other methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do, but the only difference I can really imagine is logging verbosity; I would expect None to not-or-barely log, but Err to log saying there was a communication error. We can happily do this as a follow-up if we decide to change the caller's behaviour :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that it would avoid creating error strings for cache misses. But yea, minor.

This allows any `CommandRunner` to be wrapped and transparently cache
all process executions it performs.

Still TODO:
* Wire up Core to actually use this (probably behind a flag).
@illicitonion illicitonion force-pushed the dwagnerhall/local-process-execution-cache/cache branch from e42f5b2 to c3d2501 Compare July 11, 2019 11:13
@illicitonion illicitonion merged commit fd346c5 into pantsbuild:master Jul 11, 2019
@illicitonion illicitonion deleted the dwagnerhall/local-process-execution-cache/cache branch July 11, 2019 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants