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

Dynamically determine whether to pool for wasmtime serve #8610

Merged

Conversation

alexcrichton
Copy link
Member

This commit aims to address #8607 by dynamically determining whether the pooling allocator should be used rather than unconditionally using it. It looks like some systems don't have enough virtual memory to support the default configuration settings so this should help wasmtime serve work on those systems.

Closes #8607

This commit aims to address bytecodealliance#8607 by dynamically determining whether the
pooling allocator should be used rather than unconditionally using it.
It looks like some systems don't have enough virtual memory to support
the default configuration settings so this should help `wasmtime serve`
work on those systems.

Closes bytecodealliance#8607
@alexcrichton
Copy link
Member Author

I'm going to seek confirmation this fixes the issue before merging since I don't have a system to test on myself.

@matsbror
Copy link

I can confirm that it works on the VisionFive 2 board (RISCV64) and the Nvidia Jetson Nano board.

@alexcrichton
Copy link
Member Author

Thanks for the confirmation!

@alexcrichton alexcrichton added this pull request to the merge queue May 14, 2024
Merged via the queue into bytecodealliance:main with commit 9b9a796 May 14, 2024
22 checks passed
@alexcrichton alexcrichton deleted the conditionally-pool-on-serve branch May 14, 2024 15:27
alexcrichton added a commit to alexcrichton/spin that referenced this pull request May 14, 2024
This commit is intended to address fermyon#2119 and mirror
bytecodealliance/wasmtime#8610. The base problem is that some systems
are configured with smaller amounts of virtual memory than other
systems, for example some aarch64 and riscv64 systems are shown to have
only 39 bits of virtual address space rather than the 48 by default on
x86_64. This means that the pooling allocator can't be initialized on
these platforms since it needs more virtual memory than that.

This changes Spin to dynamically choosing whether to use the pooling
allocator. It's still used by default in Wasmtime but a dynamic probe is
performed to determine whether it's going to work first. While here I
also added an env var to control this behavior for an escape hatch if
that's needed in the future too.

Closes fermyon#2119
alexcrichton added a commit to alexcrichton/spin that referenced this pull request May 14, 2024
This commit is intended to address fermyon#2119 and mirror
bytecodealliance/wasmtime#8610. The base problem is that some systems
are configured with smaller amounts of virtual memory than other
systems, for example some aarch64 and riscv64 systems are shown to have
only 39 bits of virtual address space rather than the 48 by default on
x86_64. This means that the pooling allocator can't be initialized on
these platforms since it needs more virtual memory than that.

This changes Spin to dynamically choosing whether to use the pooling
allocator. It's still used by default in Wasmtime but a dynamic probe is
performed to determine whether it's going to work first. While here I
also added an env var to control this behavior for an escape hatch if
that's needed in the future too.

Closes fermyon#2119

Signed-off-by: Alex Crichton <alex@alexcrichton.com>
calebschoepp pushed a commit to calebschoepp/spin that referenced this pull request May 15, 2024
This commit is intended to address fermyon#2119 and mirror
bytecodealliance/wasmtime#8610. The base problem is that some systems
are configured with smaller amounts of virtual memory than other
systems, for example some aarch64 and riscv64 systems are shown to have
only 39 bits of virtual address space rather than the 48 by default on
x86_64. This means that the pooling allocator can't be initialized on
these platforms since it needs more virtual memory than that.

This changes Spin to dynamically choosing whether to use the pooling
allocator. It's still used by default in Wasmtime but a dynamic probe is
performed to determine whether it's going to work first. While here I
also added an env var to control this behavior for an escape hatch if
that's needed in the future too.

Closes fermyon#2119

Signed-off-by: Alex Crichton <alex@alexcrichton.com>
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.

pooling allocator should take virtual address space into account (on aarch64 and riscv64)
3 participants