Stream: git-wasmtime

Topic: wasmtime / PR #8802 wasmtime: Take guest-profiler samples...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 13 2024 at 22:49):

jameysharp opened PR #8802 from jameysharp:profile-hostcalls to bytecodealliance:main:

Otherwise it's difficult to interpret the profiles because whatever happened to be the last sample before the hostcall appears to be taking the entire time of the hostcall.

Ideally we'd do more to highlight which hostcall is running or use markers to delimit the boundaries of each hostcall, but this should be a good starting point.

I haven't tested this at all yet, just wanted to share it as something to point to for folks who are pushing the current limits of the guest profiler.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:40):

jameysharp updated PR #8802.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:45):

jameysharp updated PR #8802.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:47):

jameysharp edited PR #8802:

The output of the guest profiler can be misleading around hostcalls. Whatever happened to be the last sample before the hostcall appears to run for the entire time of the hostcall. This change ensures that we can see the actual call stack at the time of the hostcall, and get a visual indication of which periods are not spent executing guest code.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:54):

jameysharp commented on PR #8802:

@alexcrichton, this PR means that the guest profiler will require the new call-hook feature. How do you think we should set the defaults for these features?

I could imagine for example that profiling and call-hook would both be off-by-default in the wasmtime crate so that embedders don't take the performance hit unless they ask for it, but enabled by default in wasmtime-cli so that CLI users have the full profiler available.

Alternatively, the profiler's use of call-hooks could be made conditional on whether call-hook is enabled, but 1) I think that's going to be a bit ugly and 2) the new functionality makes the profiles quite a bit easier to interpret correctly so I kind of want it always available.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:54):

jameysharp has marked PR #8802 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:54):

jameysharp requested pchickey for a review on PR #8802.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 00:54):

jameysharp requested wasmtime-core-reviewers for a review on PR #8802.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 01:51):

alexcrichton commented on PR #8802:

Is the use case you're primarily interested in the CLI itself? If so could we thread that needle by making the hooks conditional but unconditionally enabling them in the CLI?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 16:14):

jameysharp commented on PR #8802:

I do want this available in the CLI but I also want it in Fastly's CLI embedding of Wasmtime (Viceroy). So as long as all embedders have the option to turn this on then I'm happy.

I'll push a commit for that in a bit.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 16:32):

fitzgen commented on PR #8802:

Can we make it so that the sample-at-hostcall functionality only happens when the call hook feature is enabled and then embeddings can enable or disable the feature to get more functionality (at the cost of some host-wasm call overhead) as they choose?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:29):

jameysharp commented on PR #8802:

I just realized that the CallHook type (the enum indicating which kind of transition happened) is not guarded by the call-hook feature, which makes this simpler than I expected. That means the part of the guest profiler that's in the wasmtime crate does not actually require the call-hook feature; it can unconditionally provide a call_hook method for an embedder to use if they want to.

The embedder is responsible for arranging for that function to be called from an actual call-hook, and so it's their responsibility to enable the call-hook feature if they want to use that part of the guest profiler. In principle I think an embedder could also use other means to pass the same information to the profiler if they wanted to.

Hopefully that makes everyone happy?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:34):

alexcrichton commented on PR #8802:

Oh nice! That sounds good to me :+1:

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:37):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:37):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:37):

alexcrichton created PR review comment:

Stray submodule change?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:40):

jameysharp submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 17:40):

jameysharp created PR review comment:

Ah dang, thanks for catching that!

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 18:04):

jameysharp requested wasmtime-default-reviewers for a review on PR #8802.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 18:04):

jameysharp updated PR #8802.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2024 at 19:08):

jameysharp merged PR #8802.

Last updated: Nov 22 2024 at 16:03 UTC