eoc-meter: say where the sampler-re-reads property is actually pinned #262
1 changed files with 12 additions and 0 deletions
|
|
@ -3401,6 +3401,18 @@ mod macos_ioreport {
|
|||
// inside it. One value here is therefore no evidence of a sampler that
|
||||
// does not sample, and asserting it was a rise the probe must also see
|
||||
// failed once in ~300 CI runs on an otherwise green tree.
|
||||
//
|
||||
// Nothing is lost by not asserting it here: that the sampler re-reads
|
||||
// is already pinned deterministically, per sample, by the scripted
|
||||
// probes -- `probe_with_a_single_batch_jump_is_frozen` drives
|
||||
// `GPU Energy` to a different value at every sample and asserts each
|
||||
// one is what the rule was handed, as does
|
||||
// `probe_with_one_die_live_and_one_frozen_is_frozen`. A sampler that
|
||||
// cached one reading fails those on sample 1, on every host. So do
|
||||
// not restore a hardware assertion here believing this is uncovered:
|
||||
// no rail on the CI host reliably moves inside the probe's window
|
||||
// (its CPU rails are frozen), so there is no sound hardware witness
|
||||
// to assert on.
|
||||
lines.push(if values.len() >= 2 {
|
||||
format!("{}: moved {lo} -> {hi}, the probe read {} distinct values within it", key.0, values.len())
|
||||
} else {
|
||||
|
|
|
|||
Loading…
Reference in a new issue