Closed tilsche closed 1 year ago
As far as I'm concerned, we can delete that code path. Neither Google nor a search in the Linux kernel code finds anything regarding such an issue ever existing and git blame
on the comment about the swap bug points to the initial import from svn.
Given that all information points to it being fixed for at least 7 years (the git-preserved history of lo2s), I tend to agree.
But at the same time I have to admit that I am utterly curious what it is/was.
I encountered a trace in which a collected metric
uncore_clock/clockticks/
becameNaN
at some point and never reverted to a valid state.After a brief look at the code, it appears that
CounterBuffer
's state could becomeNaN
in casediff_enabled > diff_running
anddiff_running == 0
. We need to avoid those cases. Note that this happend on a Kernel, 5.19.1. Not sure what is special withtime_enabled
/time_runing
for PMU counters - and not sure if that "swap" bug is still in effect. Maybe we can also simplify the code now and only consider non-broken kernels? In any case there should be logging / handling of cases that result inNaN
.