[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: [Xen-devel] Time went backwards

On 14 Mar 2006, at 15:43, Rik van Riel wrote:

Actually, we come into timer_interrupt() sometimes with
blocked + stolen > delta_cpu, so the bugfix is valid.

I just no longer understand how we can get into this

Could be due to horrendous clock jitter across CPUs.

Not on a single CPU system ;)

Hmmm... well, a few suggestions:
1. The first do-while loop in timer_interrupt() in time-xen.c aims to get a consistent snapshot of blocked, stolen and delta_cpu, by checking timestamp-info version numbers in the two while predicates. I just added a rmb() to time_values_up_to_date() -- required for absolute accuracy and will also act as a compiler barrier too. But the likelihood of gcc having moved that test earlier is very small I think. :-) If it had, though, you could end up with a later snapshot of stolen/blocked than of delta_cpu, which would be bad. 2. Maybe the time synchronising code in Xen is broken. I tested it pretty hard when I implemented it, but you never know. It would be bad if time could step backwards during local_time_calibration() in xen/arch/x86/time.c. It might be worth doing a before-and-after check in that function (e.g., see whether value returned by get_s_time() gets smaller).

This bug can't be *that* hard to find on a single CPU system. :-)

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.