MemtraceDOCS

CPU governor validation

Release-specific CPU governor validation: tested platforms, indexing benchmark methodology, measured results and coverage limits.

CPU governor validation scope#

This reference records validation completed on September 6, 2026 for the macOS integration shipped in 1.1.13-nightly.20260906.6948f83. It separates observed results from the general resource-management behavior described in the CPU governor reference.

The release added native macOS power, user-idle and memory-pressure readings. Memory classification now uses the operating system's pressure level, correcting a case where a zero available-memory estimate could incorrectly request a background-work pause. The governor remains opt-in and defaults to off.

CPU governor platform validation#

Memtrace's CPU governor manages work on macOS Apple Silicon using native platform APIs, with no M5-only activation requirement. Hardware validation and build coverage for this release are recorded below.

EnvironmentValidation completed
Physical M5 Pro, 24 GiB, macOS 26.5Native host signals, CoreML execution, full-repository indexing and published-package runtime checks.
Virtual M5 Max ARM64, 48 GiB, macOS 26.5.1macOS CI: CoreML profiling, native lifecycle, memory pressure and focused governor tests.
Windows x64; Linux x64 and ARM64Release build and packaging checks.

Physical M1–M4 systems, smaller-memory configurations and older macOS versions remain outside this validation set. Windows/Linux build coverage does not constitute physical device testing. Platform compatibility and tested hardware are distinct coverage measures.

The published Mac package completed 24 fresh embeddings and 48 routing checks, including saved disable and hook cleanup following a forced daemon crash. Separate native and CI profiles confirmed CoreML execution. These are correctness and lifecycle checks; they do not measure foreground responsiveness or energy consumption.

CPU governor indexing benchmark#

One enabled/disabled pair indexed the full Memtrace repository on the physical M5 Pro environment. Both runs used fresh stores, disabled embedding-result caches and identical source/history manifests. Each completed 51,837 fresh embeddings with zero failures or cache hits; neither run requested a bulk pause.

GovernorElapsed indexing timeFresh embeddingsDaemon CPU time
Off44m 50s51,8371,768.68 CPU-seconds
On51m 13s51,8372,004.59 CPU-seconds

The enabled run took 6m 22s longer, or 14.2%, calculated from unrounded timings. Concurrent CPU load differed: 10.52% during the enabled run and 4.95% during the disabled run. GPU contention was uncontrolled. The elapsed-time difference therefore does not isolate the governor's effect or define an expected slowdown for other deployments.

CPU governor result interpretation#

The completed benchmark establishes successful indexing in both modes under the recorded conditions. It did not measure foreground application latency, energy use or battery life, and it demonstrated no reduction in total CPU work. Foreground responsiveness remains a design objective requiring separate workload measurements.

Equal embedding counts do not establish equality of every stored vector. Generated community grouping differed between runs. Controlled performance evaluation should hold the repository, power state, cache conditions and concurrent workload constant, repeat both modes, and report foreground latency alongside indexing completion time.