Jed Davis wrote:

>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
>  
>
[Keep in mind a specific environment: AMD 64 X4, gcc4, -march=athlon.
Intel seems to do fine given the reports in teck-kern@.]

That confuses me. xen/xen/clock.c:xen_timer_handler does assume that
process_system_time is always less then shadow_system_time. If that is
violated delta becomes negative.
In that situation I have seen the hardclock(9) catch up loop repeatedly
calling hardclock for a long time in a tight loop on the amd. This is 
the hang
Thor and I see.

Could it be that "delta >= NS_PER_TICK" is effectively doing an unsigned 
comparison here
(NS_PER_TICK is unsigned)? (CPUFLAGS is set to -march=athlon - gcc4 is 
used - compiler
or unsigned propagation feature?).
furthermore the negative delta will be assigned to ci->ci_cc.cc_denom.
Is this wanted? The microtime interpolation attempts then generate time 
going backwards
IFAICS and that is handled by clamping. Clamping is happening as debug 
output shows.
I have yet to understand how process_system_time can get ahead of 
shadow_system_time.
process_system_time is static and only incremented for positive deltas 
and should always
stay less than shadow_system_time (unless  shadow_system_time goes 
backward) or stall (if the comparison would work)
until shadow_system_time passes processed_system_time again.

>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.
>  
>
need to think about that - too early in the morning :-) I am still puzzled
about the current effects in the xen_timer_handler().

>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.
>
>  
>
Frank