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

wasmtime serve can't run components requiring >10MB of memory by default #8846

Closed
dicej opened this issue Jun 20, 2024 · 7 comments · Fixed by #8849
Closed

wasmtime serve can't run components requiring >10MB of memory by default #8846

dicej opened this issue Jun 20, 2024 · 7 comments · Fixed by #8849

Comments

@dicej
Copy link
Contributor

dicej commented Jun 20, 2024

Since wasmtime serve was switched to using the pooling allocator, which defaults to a memory limit of 10MB, components built with e.g. componentize-py or componentize-dotnet will no longer run by default. Also, since there is currently no CLI option to override that memory limit, the only workaround is to disable the pooling allocator entirely using wasmtime serve -O pooling-allocator=n.

I propose that we address this with the following changes:

  • Increase the default memory limit in the pooling allocator to something like 100MB
  • Allow the default to be overridden via a CLI option
  • Provide a helpful suggestion to use that option when the component can't be run due to the memory limit
@dicej
Copy link
Contributor Author

dicej commented Jun 20, 2024

See also #8504 and bytecodealliance/componentize-py#94

@dicej
Copy link
Contributor Author

dicej commented Jun 20, 2024

Also, (mainly to help search engines find this issue) this is the kind of error message you get: Error: memory index 0 has a minimum page size of 223 which exceeds the limit of 160

@alexcrichton
Copy link
Member

Can you test whether -Opooling-max-memory-size=N enables running these components? Sorry I keep meaning to raise the limit here and keep forgetting, but I also want to confirm orthogonally that this option works since that's what it's supposed to do

@dicej
Copy link
Contributor Author

dicej commented Jun 20, 2024

 $ wasmtime --version
wasmtime-cli 21.0.1 (cedf9aa0f 2024-05-22)
 $ wasmtime serve -Opooling-max-memory-size=160 -S cli target/component.wasm
error: unknown -O / --optimize option: pooling-max-memory-size

Maybe that's new on main?

@alexcrichton
Copy link
Member

I think that might be Wasmtime 21+, what version do you have for that?

@dicej
Copy link
Contributor Author

dicej commented Jun 20, 2024

Sorry, just edited the comment; it's 21.0.1

@alexcrichton
Copy link
Member

Oh sorry, for some reason I had Wasmtime 22 installed instead of the 21 version, which explains this!

alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Jun 20, 2024
This commit raises the default setting of `max_memory_size` in the
pooling allocator from 10M to 4G. This won't actually impact the virtual
memory reserved in the pooling allocator because we already reserved 6G
of virtual memory for each linear memory this instead allows access to
all of it by default. This matches the default behavior of Wasmtime for
the non-pooling allocator which is to not artificially limit memory by
default.

The main impact of this setting is that the memory-protection-keys
feature, which is disabled by default, will have no effect by default
unless `max_memory_size` is also configured to something smaller than
4G. The documentation has been updated to this effect.

Closes bytecodealliance#8846
github-merge-queue bot pushed a commit that referenced this issue Jun 20, 2024
This commit raises the default setting of `max_memory_size` in the
pooling allocator from 10M to 4G. This won't actually impact the virtual
memory reserved in the pooling allocator because we already reserved 6G
of virtual memory for each linear memory this instead allows access to
all of it by default. This matches the default behavior of Wasmtime for
the non-pooling allocator which is to not artificially limit memory by
default.

The main impact of this setting is that the memory-protection-keys
feature, which is disabled by default, will have no effect by default
unless `max_memory_size` is also configured to something smaller than
4G. The documentation has been updated to this effect.

Closes #8846
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 a pull request may close this issue.

2 participants