Nick Piggin wrote:
Peter Williams wrote:
The interesting question is: How does now get to be less than timestamp? This probably means that timestamp_last_tick is not a good way of getting a value for "now".
It is the best we can do.
You could use sched_clock() which will do better. The setting of timestamp in schedule() gives you a pretty good chance that it's value will be greater than timestamp_last_tick.
By the way, neither is sched_clock() when measuring small time differences as it is not monotonic (something that I had to allow for in my scheduling code).
I'm pretty sure it is monotonic, actually. I know some CPUs can execute
rdtsc speculatively, but I don't think it would ever be sane to execute
two rdtsc's in the wrong order.
I have experienced it going backwards and I assumed that it was due to the timing code applying corrections. (You've got two choices if your clock is running fast: one is to mark time until the real world catches up with you and the other is to set your clock back to the correct time when you notice a discrepancy. I assumed that the second strategy had been followed by the time code and didn't bother checking further because it was an easy problem to sidestep.) Admittedly, this behaviour
was only observed when measuring very short times such as the time spent on the runqueue waiting for CPU access when the system was idle BUT it was definitely occurring. And it only occurred on a system where the lower bits of the values returned by sched_clock() were not zero i.e. a reasonably modern one. It was observed on a single CPU machine as well and was not, therefore, a result of drift between CPUs.