You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.
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.
Reproduced how the former unscaled calculation interprets Mach ticks directly as nanoseconds.
Exercised the current timebase conversion and confirmed that it produces the expected nanosecond value.
Checked the accounting-unit contract against Apple XNU source and Darwin-compatible interfaces.
Confirmed that a live macOS process sample cannot run on the available Linux environment.
Validated that removing the timebase scaling or treating Mach ticks as nanoseconds would be incorrect, based on cross-checks with Apple XNU sources.
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
weaver statusunderreports 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_rusageuser and system ticks usingmach_timebase_infobefore returning the existing nanosecond result. Use a 128-bit intermediate to avoid overflow during scaling. The regression calls the production function between twoCLOCK_PROCESS_CPUTIME_IDreads. 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.creproduced this on refreshed, clean defaultbf2da4cwith macOS 27.0, build 26A428:Validation with
DEVELOPER_DIR=/Library/Developer/CommandLineToolsand--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.zig fmt --check host/src/macos_host.zigandgit 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.jsonretains 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.
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.