[release-branch.go1.22] runtime: fix EvFrequency event value on Windows in the new...

The value produced for the EvFrequency event on Windows is missing the
fact that the cputicks clock gets divided. This results in durations
that are consistently wrong by the same factor (about 256).

For #65997.
Fixes #66201.

Change-Id: I930cbfce3499d435c20699f41c11e3227d84f911
Reviewed-on: https://go-review.googlesource.com/c/go/+/567937
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit 707eba9b941230be1afe809466afa3465ed60fdb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/570195
Reviewed-by: Than McIntosh <thanm@google.com>

diff --git a/src/runtime/trace2time.go b/src/runtime/trace2time.go
index 8a4499ef617483c5b75c3ab437128893a30d487a..7a7a53e7d8d5f3fda9ddd96b5b3f7bda5c1c8faf 100644 (file)
--- a/src/runtime/trace2time.go
+++ b/src/runtime/trace2time.go
@@ -61,7 +61,7 @@ func traceClockNow() traceTime {
 func traceClockUnitsPerSecond() uint64 {
        if osHasLowResClock {
                // We're using cputicks as our clock, so we need a real estimate.
-               return uint64(ticksPerSecond())
+               return uint64(ticksPerSecond() / traceTimeDiv)
        }
        // Our clock is nanotime, so it's just the constant time division.
        // (trace clock units / nanoseconds) * (1e9 nanoseconds / 1 second)