Keir Fraser wrote:
On 5/3/08 17:25, "Dave Winchell" <dwin...@virtualiron.com> wrote:
In 2.6.9, it looks like cur_timer->mark_offset() call from
timer_interrupt in
32 bit arch/i386/kernel/time.c invokes, for hpet, mark_offset_hpet(),
which computes
missed ticks based on hpet counter. mark_offset_pit() does nothing.
mark_offset_tsc() does compute missed ticks.
In 64 bit 2.6.9, the timer_interrupt() in arch/x86_64/time.c does hpet
reads directly HPET_T0_CMP, HPET_COUNTER to calculate missed ticks.
So from the code perspective, it looks like missed ticks are computed
for 32
and 64 bit Linux using hpet clocksource.
Ah. I looked at 2.6.18 which seems to have neither the mark_offset nor the
GENERIC_TIME approach in its arch/i386 time code. But yeah, it does look
like in general Linux 2.6 is robust to missed ticks when using hpet. That's
good.
Do you see and simply ignore warning messages from 64-bit Linux when using
hpet (or otherwise not doing missed-tick handling in Xen), by the way? I
know 64-bit Linux is keen to warn about missed ticks, although it does look
like at least the warning is one shot.
I see the one shot messages on 64 bit and no complaints at all on 4u432
Linux.
And I have been ignoring them.
78 messages in com.xensource.lists.xen-develRe: (progress on hpet accuracy) and R...
.patch