Frank Kardel <kardel@netbsd.org> writes:
[arch/xen]
> My observations:
>     - my builds where gcc4.
>     - it is running on an Athlon 64 X2
>     - I was seeing process_system_time getting ahead of
>      shadow_system_time.

That can happen: shadow_system_time is the time when Xen last updated
the shared time info; the domain has to extrapolate from that using
the TSC to get the current time on that scale.  processed_system_time
is when, on that timescale, the last hardclock(9) call should have
occurred -- it may have actually occurred later than that, in the case
of CPU contention.

...oh.  That means that, in the xen timecounter I'm in the middle of
writing, I'll need to bias the clock back when I call hardclock(9),
doesn't it.

So, how much difference was there, and what version of Xen?  Xen 2 updates
the shared info every tick, but with Xen 3 it's only once per second IIRC.

Also, this reminds me: we don't schedule clock interrupts while we're
running, because Xen will send one every 10 ms anyway; this might not
be the best thing, as those events may be arbitrarily out of sync with
when we want them.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))