diff --git a/meetings/wasmtime/2021/wasmtime-09-02.md b/meetings/wasmtime/2021/wasmtime-09-02.md
index 86bdf540ed..b3c0a613b0 100644
--- a/meetings/wasmtime/2021/wasmtime-09-02.md
+++ b/meetings/wasmtime/2021/wasmtime-09-02.md
@@ -18,4 +18,74 @@
 
 ### Attendees
 
+- Nick Fitzgerald (NF)
+- Alex Crichton (AC)
+- Benjamin Bouvier (BB)
+- Till Schneidereit (TS)
+- Pat Hickey (PH)
+- Chris Fallin (CF)
+- Andrew Brown (AB)
+- Johnnie L Birch (JB)
+- Dan Gohman (DG)
+- Will Woods (WW)
+
 ### Notes
+
+- NF: heads-up: intern from KTH to work on wasm-mutate
+  - take a wasm binary, parse it, make some transformation (optionally
+    semantics-preserving). Will help fuzzing.
+- AB: will be on sabbatical for two months (starting in 10 days)
+  - all: have fun!
+- AC: improvements to module load time
+  - https://github.com/bytecodealliance/wasmtime/issues/3230#issuecomment-910528582
+  - Making loading precompiled modules fast. Now basically `mmap` and run.
+    About 100x faster.
+  - Precompiled modules are now valid ELF modules. Allows `objdump -d` to look
+    at compiled output code.
+  - TS: new API to make this work?
+  - AC: currently "deserialize a module from these bytes"; now also have
+    "deserialize a module from this file" to allow mmap. Might add other
+    flavors as well for other use-cases.
+  - JB: Ready to use now? (AC: yes!) Better alternative to `wasm2obj`?
+    - AC: wasm2obj is still there; but we can now do `wasmtime compile` and
+      disassemble the resulting ELF. This means we see the exact code whereas
+      `wasm2obj` sometimes diverged in settings.
+  - TS: this was one of the big remaining things where we knew there's work to
+    do; now it's done!
+  - TS: no full numbers yet to compare against Lucet but if the measurements
+    scale up this should be faster than Lucet. wasmtime was originally 20x
+    slower. Lucet does dlopen; dlopen needs to do more relocations.
+  - AC: one day would be nice to be able to statically link a compiled Wasm
+    module into your application. RLBox-style. Not quite there yet.
+    - TS: talked to RLBox a while ago, seemed clear wasmtime wasn't right for
+      RLBox at the time because of compilation strategy and also call overhead.
+      Taking a look at call overhead now (wasm->host, host->wasm) especially
+      for non-Rust embeddings.
+  - TS: using direct calls -- makes things faster?
+    - AC: probably!
+    - CF: spectre mitigations disable indirect predictor entirely or partly (?)
+      so indirect calls are somewhat expenive; this should be better
+  - TS: think that maybe we did direct calls before but maybe not?
+    - CF: we just did an Abs8 constant loaded into a register, to avoid
+      problems with range
+    - CF: relevant on aarch64, part of Alex's patch was careful work to make
+      long-range (> 64MiB on aarch64) calls work. Still an issue with
+      intra-function branches but that issue was there before; other limits
+      come into play as well.
+      - AC: yes, e.g. regalloc limits.
+      - CF: scaling up to large code and hitting implementation limits is a
+        bigger issue that we should definitely address
+
+- TS: APIs; stable C API, unstable C++ API on top of it, call performance
+  - supporting calls into native C-ABI functions; more difficult than in Rust
+    where we can monomorphize around the function we're given
+  - AC: not sure if this will pan out. Would involve JIT compilation between
+    wasmtime-defined layers and outside world.
+  - DS: impossible to expose wasm functions as C-ABI function pointer?
+    - AC: lots of stuff to set up, like setjmp, etc
+  - AC: call overhead Rust to wasm is ~20ns, C overhead is ~30ns, both with no
+    args, higher with args
+    - TS: all runtimes are slow enough that this doesn't stick out; in other
+      runtimes calls have to go through JS
+  - AC: want to get at least wasm to host overhead as low as possible
+