Subject: Re: HEADS UP: timecounters (branch simonb-timecounters) merged into
To: Jed Davis <jdev@panix.com>
From: Frank Kardel <kardel@netbsd.org>
List: tech-kern
Date: 07/03/2006 09:25:23
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