add a config field that allows us to mlock() module mmaps into RAM

[pchickey]

Needs benchmarking before this is considered seriously.

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[github-actions]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• If you added a new Config method, you wrote extensive documentation for
  it.

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in wasmtime_fuzzing::Config (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See our docs on fuzzing for more details.

• If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

---

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

[alexcrichton]

With copy-on-write initialization of memories another thing we may wish to measure and/or learn about is the behavior here with respect to new mappings. For example with Module::deserialize_file we mmap the whole file into memory and use that for a Module, but then we'll also mmap the memory image part of the file into new linear memories for each instance. Even if we mlock the original Module into memory we might still run the risk that the kernel page cache doesn't have entries for the module's memory image.

One naive way we might be able to fix that is to mmap the memory image as read-only into some random address in the process, mlock it in place, and then ignore it. Theoretically whenever a future mmap of the memory image happens the kernel could realize that there's a readonly-page mapped into the address space which can be reused as the source of bytes for copy-on-write. I don't know if that's how Linux behaves though as it seems somewhat magical, but otherwise I'm not sure if we can eat the cost of possibly-slow-to-disk page faults on new memory maps at startup and ensure there's no cost in the future.

[tschneidereit]

Even if we mlock the original Module into memory we might still run the risk that the kernel page cache doesn't have entries for the module's memory image.

@alexcrichton by this, do you mean that the very first time a module is instantiated / a particular mapped page is accessed in an instance, it needs to be mapped in from disk?

If so, that's the intended behavior for this patch: basically, the idea is to not have to read all pages of all modules at startup, with the associated increases in startup time and RSS. Instead, we'd still map pages in lazily, but once we have them, we keep them around for sure.

Eagerly mapping in pages is a separate thing that we might also want to introduce support for, but I think it's best to have these be separate.

[alexcrichton]

Ah I see. I did indeed mean during instantiation and while I don't think we want to eagerly pay the cost of initializing memory (as that defeats the original purpose of lazy init) there could be a theoretical case made for the first page fault on each page should be not as slow as going to disk. That being said I don't think we can guarantee that because we can't guarantee membership in the kernel's page cache with mlock.

If we still want to lazily page things in, though, then I think this may want to use mlock2 with MLOCK_ONFAULT because currently it uses mlock which I believe guarantees that everything is resident after mlock returns so it would have rss and startup time implications.

[sunfishcode]

The macOS failure here is because mlock_with / mlock2 is only available on Linux.

[bjorn3]

What would exactly be the benefit of this change? Once a module is instantiated and run, all necessary pages should already be in memory, right? The only thing that can kick them back out again is a low memory condition, in which case mlock would require the kernel to evict other pages even if they are used more frequently.

[tschneidereit]

@bjorn3 you're right that in most contexts this doesn't make much sense. It can be useful however in settings where the goal is to have close to full memory usage at all times, but with most data being evictable because it's just there for caching purposes. In such a setting, there's often more information available on the application level than on the kernel level about which data is more important to retain, and this is an attempt to make use of that information in a better way.

[alexcrichton]

As a heads up @pchickey I just pushed to this branch. I rebased it and tweaked things a bit, but this is still not in a landable state I think.