Skip to content

fix(host): report macOS process CPU time in nanoseconds - #84

Merged
SunkenInTime merged 1 commit into
masterfrom
fix/macos-process-cpu-time
Sep 24, 2026
Merged

SunkenInTime merged 1 commit into
masterfrom
fix/macos-process-cpu-time

Conversation

@SunkenInTime

@SunkenInTime SunkenInTime commented Sep 24, 2026 •

Copy link
Copy Markdown
Collaborator

weaver status underreports macOS widget CPU usage when Mach ticks differ from nanoseconds. On this Apple M5 Pro, the timebase is 125/3, so the host reports about 1/41.67 of the actual CPU usage. This was found while measuring Weaver’s current performance profile.

Convert proc_pid_rusage user and system ticks using mach_timebase_info before returning the existing nanosecond result. Use a 128-bit intermediate to avoid overflow during scaling. The regression calls the production function between two CLOCK_PROCESS_CPUTIME_ID reads. Its 2 μs allowance comes from the two microsecond-truncated fields used by Darwin’s process CPU clock.

A minimal C caller linked directly to host/src/macos_system.c reproduced this on refreshed, clean default bf2da4c with macOS 27.0, build 26A428:

Source CPU clock before Weaver sample CPU clock after Result
Default 1,380,000 ns 33,175 ns 1,384,000 ns Failed
Fixed 1,221,000 ns 1,223,666 ns 1,226,000 ns Passed

Validation with DEVELOPER_DIR=/Library/Developer/CommandLineTools and --sysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk:

  • cd host && zig build test -Doptimize=ReleaseFast: 60 passed, 9 skipped. Restoring default’s C implementation makes exactly the new regression fail, with 59 passed, 9 skipped, 1 failed.
  • cd host && zig build -Doptimize=ReleaseFast: passed all 14 build steps.
  • App bundle signature, bundle identifier, macOS 14.2 deployment target, and absent production automation seam verified.
  • zig fmt --check host/src/macos_host.zig and git diff --check: passed.

The live hosted synthetic-widget workflow also passed with this host and the current production runtime. After an 8-second warmup, an independent 30.004-second sample measured worker CPU at 3.5678% of one core; the host status reported 3.54%. Before the fix, the same workflow reported 0.1% while the independently converted counters measured 3.594%. The host uses a rolling average and rounds individual samples, so its final value need not equal the independent interval exactly.

The local receipt at /tmp/weaver-perf-20260924/receipts/fixed-host-synthetic-r1/measurement.json retains the raw start/end counters, 125/3 timebase, process paths, and before/after status. All seven platform CI jobs and the current-head Greptile review passed, with no review findings.

This fixes measurement accuracy; it does not reduce widget CPU work.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

@greptile-apps

greptile-apps Bot commented Sep 24, 2026

Copy link
Copy Markdown

RetriggerConfidence Score: 4/5

The macOS CPU-time conversion is appropriate and does not double-scale reported process CPU usage.

What we checked:

  • Mach CPU time is converted once: The CPU-time fields are represented in Mach timebase units rather than final nanoseconds. Converting their sum with the timebase numerator and denominator produces the nanosecond value expected by the sampler. T-Rex
  • Reproduced how the former unscaled calculation interprets Mach ticks directly as nanoseconds. T-Rex
  • Exercised the current timebase conversion and confirmed that it produces the expected nanosecond value. T-Rex
  • Checked the accounting-unit contract against Apple XNU source and Darwin-compatible interfaces. T-Rex
  • Confirmed that a live macOS process sample cannot run on the available Linux environment. T-Rex
  • Validated that removing the timebase scaling or treating Mach ticks as nanoseconds would be incorrect, based on cross-checks with Apple XNU sources. T-Rex

Summary

This change corrects macOS process CPU sampling by converting Mach timebase units into nanoseconds before reporting usage, with coverage comparing the sampled value to the process CPU clock.

The updated conversion was exercised with representative Mach timebase values and checked against Apple XNU accounting behavior and Darwin interfaces. The prior unscaled interpretation would treat Mach ticks as nanoseconds and under-report CPU time.

T-Rex validation blocked

A live macOS proc_pid_rusage sample could not run because the available environment is Linux and lacks the macOS SDK, xcrun, and Xcode Command Line Tools. The host build intentionally supports only macOS and Windows. Configure VMs

Reviews (1) · Last reviewed commit: "fix(host): convert macOS CPU ticks to na..."

@SunkenInTime
SunkenInTime merged commit 85fda8c into master Sep 24, 2026
9 checks passed
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.

1 participant