[release/8.0-staging] Fix #91958: use mach_timebase_info to determine process time coefficient on macOS

[jeffhandley]

Backport of #92185 to release/8.0-staging

Customer Impact

• Customer reported
• Found internally

This has been reported by 2 customers. The first report was in September 2023 by @ForNeVeR in #91958, and they also provided the fix and tests. The issue was reported again by @huntharo in February with #98121. In that issue, @huntharo requested that this fix be backported to 8.0. As @huntharo stated:

On Mac OS X, with Apple Silicon, the System.Diagnostics.Process class returns incorrect (substantially underreported - ms when it should be seconds) CPU usage times for the process (and probably for the thread-level stats too).

I discovered this while writing a function to tune the max # of worker threads in the ThreadPool as it reduces CPU usage from 700% to 120% while increasing throughput for my project (pwrdrvr/lambda-dispatch#109). I was always computing that 0 threads would be needed because CPU usage was only going up by 20 ms per 5 seconds despite using 700% CPU.

Regression

• Yes
• No

While this isn't a product regression, it's behavior that became incorrect with Apple Silicon.

Testing

@ForNeVeR included a new test with their fix that is part of this backport. The test performs a native call and compares the API's results against the native results. As stated in the original PR:

I have compared the results of the process timing functions to the results of ps on my M2 MacBook device, and they seem to work properly after the changes.

The new tests were properly failing before the change (since we were returning values 42 times lower than the native results), and are, of course, green after the changes.

Risk

Low. This is a targeted fix that only affects PrivilegedProcessorTime, TotalProcessorTime, and UserProcessorTime on macOS. While the fix had been in main since September, a race condition bug in the original fix was found during the review of this backport. That bug was fixed in main on March 25 and cherry-picked to this backport.

The automatic backport of this fix failed due to a merge conflict in src/libraries/Common/src/Interop/OSX/Interop.Libraries.cs. That conflict arose because the preceding line to the change here was removed in 20a3350. Otherwise, the rest of the merge was clean.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

LGTM, thank you for backporting the fix @jeffhandley !

[jozkee]

@jeffhandley should this be marked as servicing consider now that #100122 (comment) got resolved? If so, do we need to email tactics?

[carlossanlop]

@jozkee I didn't find a Tactics email, so assuming this is ready (pending @jeffhandley 's or @adamsitnik 's confirmation), then yes, please send an email to Tactics and add the servicing-consider label.

[jeffhandley]

This was approved in email and needs an approval for merge. @jkotas -- you can ignore the re-review request as this can now be merged.