Changes in pooling_config.rs

698028ce - Add a configuration knob for `PAGEMAP_SCAN` (#11433)

Thu, 14 Aug 2025 22:07:53 +0000

Add a configuration knob for `PAGEMAP_SCAN` (#11433)* Add a configuration knob for `PAGEMAP_SCAN`This commit adds `PoolingAlloationConfig::pagemap_scan` and additionallyadds `-Opooling-pagemap-scan` to configure on the CLI. This is the sametri-state configuration option as `MpkEnable` so that enum was renamedto just `Enabled` and repurposed for both options.This then additionally turns the option off-by-default instead of theprevious on-by-default-if-able-to to enable more slowly rolling out thisfeature.* Fix broken test List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

ba4e22bc - Make it easier to reuse fuzzing configuration on the CLI (#10123)

Mon, 27 Jan 2025 21:34:55 +0000

Make it easier to reuse fuzzing configuration on the CLI (#10123)* Make it easier to reuse fuzzing configuration on the CLIDuring fuzzing we emit a debug log of configured options to assist withreproducing fuzz test cases outside of the fuzzing harness. Mappingoptions the fuzzer is using though to CLI flags, for example, is a bitof an art though and not obvious. Just today we've got a fuzz bug and Icouldn't figure out how to reproduce on the CLI and it turns out theissue was that I was forgetting a flag that was being configured inresponse to another flag. I got a bit fed up with constantly trying tomap one to the other, so I've decided to fix things.This commit adds a `Display for CommonOptions` implementation to the`wasmtime-cli-flags` crate. This is built on the same macro-constructioninfrastructure of all our flags making it a relatively low one-time-costto implement this. Each option value now implements not only parsing butprinting as well.Next the `wasmtime-fuzzing` crate was updated to create a`CommonOptions` first which is then in turn used to create a`wasmtime::Config`. This provides a layer to insert a log statement withto emit all configuration options in a form that can be easilycopy/pasted to the CLI to reproduce.Overall after doing this I was able to quickly reproduce the bug inquestion (yay!). The CLI flag logging is pretty verbose right now sincethe fuzzing infrastructure sets many settings redundantly to theirdefaults, but reducing flags to a minimum is expected to be relativelyeasy compared to otherwise trying to extract the options.* Fix build and dependencies from wasmtime-fuzzing* Always provide `wasmtime::MpkEnabled`It's an otherwise very small `enum` which makes it easier toconditionally compile `wasmtime-cli-flags`* Frob some crate features some more* Fix specification of `wasmtime_linkopt_force_jump_veneer` option List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

980a136e - Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

Thu, 16 Jan 2025 00:23:13 +0000

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)* Wasmtime: generalize `async_stack_zeroing` knob to cover initializationThis commit moves the knob from the `PoolingInstanceAllocatorConfig` to theregular `Config` and now controls both whether stacks are zeroed before reuseand whether they are zeroed before the initial use. The latter doesn't matterusually, since anonymous mmaps are already zeroed so we don't have to doanything there, but for no-std environments it is the difference betweenmanually zeroing the stack or simply using unininitialized memory.* Fix CLI and test builds* fix default config value* fix some more tests List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

460a4c0a - Update wasmi used during fuzzing (#9458)

Fri, 11 Oct 2024 23:06:08 +0000

Update wasmi used during fuzzing (#9458)* Fix differential fuzzing with multi-memory and poolingFix an issue found during fuzzing where when multi-memory and thepooling allocator are enabled then if MPK is detected and found thetotal number of memories needs to be increased because stores belong ina single stripe.* Update wasmi used in fuzzingPulls in differential fuzzing support for multi-memory List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

df69b9a7 - Implement the table64 extension to the memory64 proposal (#9206)

Wed, 11 Sep 2024 17:34:31 +0000

Implement the table64 extension to the memory64 proposal (#9206)This commit implements the table64 extention in both Wasmtime andCranelift.Most of the work was changing a bunch of u32 values to u64/usize.The decisions were made in align with the PR #3153 whichimplemented the memory64 propsal itself.One significant change was the introduction of `IndexType`and `Limits` which streamline and unify the handling of limitsfor both memories and tables.The spec and fuzzing tests related to table64 are re-enabled whichprovides a good coverage of the feature. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

0c0153c1 - Enforce `clippy::clone_on_copy` for the workspace (#9025)

Sat, 27 Jul 2024 01:11:06 +0000

Enforce `clippy::clone_on_copy` for the workspace (#9025)* Derive `Copy` for `Val`* Fix `clippy::clone_on_copy` for the whole repo* Enforce `clippy::clone_on_copy` for the workspace* fix some more clippy::clone_on_copy that got missed List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

906ea017 - Use bytes for maximum size of linear memory with pooling (#8628)

Fri, 17 May 2024 04:06:39 +0000

Use bytes for maximum size of linear memory with pooling (#8628)* Use bytes for maximum size of linear memory with poolingThis commit changes configuration of the pooling allocator to use abyte-based unit rather than a page based unit. The previous`PoolingAllocatorConfig::memory_pages` configuration option configuresthe maximum size that a linear memory may grow to at runtime. This is animportant factor in calculation of stripes for MPK and is also acoarse-grained knob apart from `StoreLimiter` to limit memoryconsumption. This configuration option has been renamed to`max_memory_size` and documented that it's in terms of bytes rather thanpages as before.Additionally the documented constraint of `max_memory_size` must besmaller than `static_memory_bound` is now additionally enforced as aminor clean-up as part of this PR as well.* Review comments* Fix benchmark build List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

e1f8b9b7 - Wasmtime(pooling allocator): Batch decommits (#8590)

Tue, 14 May 2024 00:23:17 +0000

Wasmtime(pooling allocator): Batch decommits (#8590)This introduces a `DecommitQueue` for batching decommits together in the poolingallocator:* Deallocating a memory/table/stack enqueues their associated regions of memory for decommit; it no longer immediately returns the associated slot to the pool's free list. If the queue's length has reached the configured batch size, then we flush the queue by running all the decommits, and finally returning the memory/table/stack slots to their respective pools and free lists.* Additionally, if allocating a new memory/table/stack fails because the free list is empty (aka we've reached the max concurrently-allocated limit for this entity) then we fall back to a slow path before propagating the error. This slow path flushes the decommit queue and then retries allocation, hoping that the queue flush reclaimed slots and made them available for this fallback allocation attempt. This involved defining a new `PoolConcurrencyLimitError` to match on, which is also exposed in the public embedder API.It is also worth noting that we *always* use this new decommit queue now. Tokeep the existing behavior, where e.g. a memory's decommits happen immediatelyon deallocation, you can use a batch size of one. This effectively disablesqueueing, forcing all decommits to be flushed immediately.The default decommit batch size is one.This commit, with batch size of one, consistently gives me an increase on`wasmtime serve`'s requests-per-second versus its parent commit, as measured by`benches/wasmtime-serve-rps.sh`. I get ~39K RPS on this commit compared to ~35KRPS on the parent commit. This is quite puzzling to me. I was expecting nochange, and hoping there wouldn't be a regression. I was not expecting a speedup. I cannot explain this result at this time.prtest:fullCo-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

ecd37470 - mpk: turn on `memory_protection_keys` during fuzzing (#7393)

Fri, 27 Oct 2023 23:53:24 +0000

mpk: turn on `memory_protection_keys` during fuzzing (#7393)This also twists the `max_memory_protection_keys` knob. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

a34427a3 - Wasmtime: refactor the pooling allocator for components (#6835)

Fri, 18 Aug 2023 21:23:47 +0000

Wasmtime: refactor the pooling allocator for components (#6835)* Wasmtime: Rename `IndexAllocator` to `ModuleAffinityIndexAllocator`We will have multiple kinds of index allocators soon, so clarify which one thisis.* Wasmtime: Introduce a simple index allocatorThis will be used in future commits refactoring the pooling allocator.* Wasmtime: refactor the pooling allocator for componentsWe used to have one index allocator, an index per instance, and give out Ntables and M memories to every instance regardless how many tables and memoriesthey need.Now we have an index allocator for memories and another for tables. An instanceisn't associated with a single instance, each of its memories and tables have anindex. We allocate exactly as many tables and memories as the instance actuallyneeds.Ultimately, this gives us better component support, where a component instancemight have varying numbers of internal tables and memories.Additionally, you can now limit the number of tables, memories, and coreinstances a single component can allocate from the pooling allocator, even ifthere is the capacity for that many available. This is to give embedders toolsto limit individual component instances and prevent them from hogging too muchof the pooling allocator's resources.* Remove unused fileMessed up from rebasing, this code is actually just inline in the indexallocator module.* Address review feedback* Fix benchmarks build* Fix ignoring test under miriThe `async_functions` module is not even compiled-but-ignored with miri, it iscompletely `cfg`ed off. Therefore we ahve to do the same with this test thatimports stuff from that module.* Fix doc links* Allow testing utilities to be unusedThe exact `cfg`s that unlock the tests that use these are platform and featuredependent and ends up being like 5 things and super long. Simpler to just allowunused for when we are testing on other platforms or don't have the compile timefeatures enabled.* Debug assert that the pool is empty on drop, per Alex's suggestionAlso fix a couple scenarios where we could leak indices if allocating an indexfor a memory/table succeeded but then creating the memory/table itself failed.* Fix windows compile errors List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

8ffbb9cf - Reimplement the pooling instance allocation strategy (#5661)

Wed, 01 Feb 2023 17:43:51 +0000

Reimplement the pooling instance allocation strategy (#5661)* Reimplement the pooling instance allocation strategy This commit is a reimplementation of the strategy by which the pooling instance allocator selects a slot for a module. Previously there was a choice amongst three different algorithms: "reuse affinity", "next available", and "random". The default was "reuse affinity" but some new data has come to light which shows that this may not always be a good default. Notably the pooling allocator will retain some memory per-slot in the pooling instance allocator, for example instance data or memory data if-so-configured. This means that a currently unused, but previously used, slot can contribute to the RSS usage of a program using Wasmtime. Consequently the RSS impact here is O(max slots) which can be counter-intuitive for embedders. This particularly affects "reuse affinity" because the algorithm for picking a slot when there are no affine slots is "pick a random slot", which means eventually all slots will get used. In discussions about possible ways to tackle this, an alternative to "pick a strategy" arose and is now implemented in this commit. Concretely the new allocation algorithm for a slot is now: * First pick the most recently used affine slot, if one exists. * Otherwise if the number of affine slots to other modules is above some threshold N then pick the least-recently used affine slot. * Otherwise pick a slot that's affine to nothing. The "N" in this algorithm is configurable and setting it to 0 is the same as the old "next available" strategy while setting it to infinity is the same as the "reuse affinity" algorithm. Setting it to something in the middle provides a knob to allow a modest "cache" of affine slots while not allowing the total set of slots used to grow too much beyond the maximal concurrent set of modules. The "random" strategy is now no longer possible and was removed to help simplify the allocator. * Resolve rustdoc warnings in `wasmtime-runtime` crate * Remove `max_cold` as it duplicates the `slot_state.len()` * More descriptive names * Add a comment and debug assertion * Add some list assertions List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

d3a61819 - Add support for keeping pooling allocator pages resident (#5207)

Fri, 04 Nov 2022 20:56:34 +0000

Add support for keeping pooling allocator pages resident (#5207)When new wasm instances are created repeatedly in high-concurrency environments one of the largest bottlenecks is the contention on kernel-level locks having to do with the virtual memory. It's expected that usage in this environment is leveraging the pooling instance allocator with the `memory-init-cow` feature enabled which means that the kernel level VM lock is acquired in operations such as: 1. Growing a heap with `mprotect` (write lock) 2. Faulting in memory during usage (read lock) 3. Resetting a heap's contents with `madvise` (read lock) 4. Shrinking a heap with `mprotect` when reusing a slot (write lock) Rapid usage of these operations can lead to detrimental performance especially on otherwise heavily loaded systems, worsening the more frequent the above operations are. This commit is aimed at addressing the (2) case above, reducing the number of page faults that are fulfilled by the kernel. Currently these page faults happen for three reasons: * When memory is first accessed after the heap is grown. * When the initial linear memory image is accessed for the first time. * When the initial zero'd heap contents, not part of the linear memory image, are accessed. This PR is attempting to address the latter of these cases, and to a lesser extent the first case as well. Specifically this PR provides the ability to partially reset a pooled linear memory with `memset` rather than `madvise`. This is done to have the same effect of resetting contents to zero but namely has a different effect on paging, notably keeping the pages resident in memory rather than returning them to the kernel. This means that reuse of a linear memory slot on a page that was previously `memset` will not trigger a page fault since everything remains paged into the process. The end result is that any access to linear memory which has been touched by `memset` will no longer page fault on reuse. On more recent kernels (6.0+) this also means pages which were zero'd by `memset`, made inaccessible with `PROT_NONE`, and then made accessible again with `PROT_READ | PROT_WRITE` will not page fault. This can be common when a wasm instances grows its heap slightly, uses that memory, but then it's shrunk when the memory is reused for the next instance. Note that this kernel optimization requires a 6.0+ kernel. This same optimization is furthermore applied to both async stacks with the pooling memory allocator in addition to table elements. The defaults of Wasmtime are not changing with this PR, instead knobs are being exposed for embedders to turn if they so desire. This is currently being experimented with at Fastly and I may come back and alter the defaults of Wasmtime if it seems suitable after our measurements. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs

b14551d7 - Refactor configuration for the pooling allocator (#5205)

Fri, 04 Nov 2022 20:06:45 +0000

Refactor configuration for the pooling allocator (#5205)This commit changes the APIs in the `wasmtime` crate for configuring the pooling allocator. I plan on adding a few more configuration options in the near future and the current structure was feeling unwieldy for adding these new abstractions. The previous `struct`-based API has been replaced with a builder-style API in a similar shape as to `Config`. This is done to help make it easier to add more configuration options in the future through adding more methods as opposed to adding more field which could break prior initializations. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/pooling_config.rs