Kevin Hilman wrote:
On ARM, I'm noticing the 'bug' message from check_critical_timing()
where two calls to get_cycles() are compared and the 2nd is assumed to
be >= the first.
This isn't properly handling the case of rollover which occurs
relatively often with fast hardware clocks and 32-bit cycle counters.
Is this really a bug? If the get_cycles() can be assumed to run between
0 and (cycles_t)~0, using the right unsigned math could get a proper
delta even in the rollover case. Is this a safe assumption?
I was concerned about that as well back when I was getting the
instrumentation functional on the pxa270 as the rollover could
be as short as ~8s which wasn't really long enough for test
validation. However there is a /64 prescaler on that ARM core
(and others) which can function as a bandaid and extend the range
to ~8minutes.
I wasn't able to convince myself in a quick read of the code if
roll over was being detected/corrected (though it certainly may).
But even if not the only requirement needed to do so would be to
assure any two consecutive data points logged per CPU were spaced
apart less than the counter's wrap interval. Given the periodic
events being logged in the normal course of operation this condition
would certainly be met.
-john
--
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
