-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling zeros in readPerfStat #2632
Conversation
While working on the PR I noticed following linter issues:
I will fix them in separate commit. |
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@critical.today>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@wacuuu Could you check this fix? |
@@ -112,12 +112,17 @@ func readPerfStat(file readerCloser, name string, cpu int) (*info.PerfStat, erro | |||
} | |||
|
|||
scalingRatio := 1.0 | |||
if perfData.TimeEnabled != 0 { | |||
if perfData.TimeRunning != 0 && perfData.TimeEnabled != 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that the same fix should be provided for uncore perf events, see this line
perf/collector_libpfm_test.go
Outdated
ScalingRatio: 1.0, | ||
Value: 0, | ||
Name: "some metric", | ||
Cpu: 4, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For complicity:
missing the testcase that started whole of the issue:
{ Value: 0, TimeEnabled: 3, TimeRunning: 0, }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
I'll leave this open for a day to let you fix the remaining comments above |
@dashpole I think it can be merged :) |
Adds more robust handling for zeros in
readPerfStat
and fixes #2629 (hopefully).