Messages in this thread | | | Subject | Re: 2.6.18-rt7: rollover with 32-bit cycles_t | From | Daniel Walker <> | Date | Tue, 07 Nov 2006 19:23:41 -0800 |
| |
On Tue, 2006-11-07 at 17:36 -0800, 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?
Seems like the check should really be using something like time_before() time_after() which takes the rollover into account .. What I don't understand is why we don't see those on x86 ..
Daniel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |