Keir Fraser wrote:
On 5/3/08 15:06, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:
As for the code structure, I tried layering on vpt.c and had trouble
doing so. Therefore, I focused on a direct approach. I'll describe the
approach
shortly, after I run tests with other loads and guests.
Are you targeting only 64-bit Linux guests? 32-bit Linux cannot tolerate
missed ticks, and I want only one missed-tick algorithm in Xen: currently
that is vpt.c.
No, my results are for 32 bit Linux as well, at least 4u432.
It turns out that for hpet, (rh4u4) 32 bit Linux does handle missed ticks.
I need to try other 32 bit Linux versions, as well as Windows, to see how
broad this behaviour is.
Looking at the code for 2.6.20, it appears to me that if CONFIG_GENERIC_TIME
is set then missed ticks are handled for hpet for 32 bit and 64
bit Linux (see update_wall_time() and read_hpet()).
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.
regards,
Dave
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home