Keir,
Attached is a fix for pt_process_missed_ticks().
Without this fix, systems run very erratically and some
guests panic on boot complaining that timer interrupts
are not working. As you can imagine.
Also, I have some longer term measurements of the
accuracy of the sync and async methods.
The hardware is an eight cpu AMD box. Two eight
vcpu guests, rh4u4-64 and sles9sp3-64.
All vcpus running loads.
Method Test duration Clock errors
SYNC 56000 sec 6.4, 6.7 sec (.012%)
ASYNC 52000 sec 13, 19 sec (.036%)
More testing should be done to validate the significance
of this difference.
regards,
Dave
Dave Winchell wrote:
Keir Fraser wrote:
On 3/11/07 21:17, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:
Thanks for applying the fixes in the last submit.
In moving the test for no_missed_tick_accounting into
pt_process_missed_ticks()
you forgot to add the scheduling part.
Actually it was deliberate, but clearly it was one code
simplification too
far: thanks for spotting it! I'll go the async route, but we do need
to set
pending_intr_nr to 1. We can't leave that out -- the point of the async
route is to send a tick to the vcpu immediately, since it hasn't had
one for
more than a tick period. If we wait for the timeout to do that then
we have
to wait a whole extra period after the vcpu is re-scheduled.
Attached is my proposed patch. I think it's quite neat. :-)
It looks good to me.
thanks,
Dave
-- Keir
diff -r dfe9c0c10a2c xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c Mon Nov 05 13:23:55 2007 +0000
+++ b/xen/arch/x86/hvm/vpt.c Wed Nov 07 08:55:45 2007 -0500
@@ -59,7 +59,7 @@ static void pt_process_missed_ticks(stru
if ( mode_is(pt->vcpu->domain, no_missed_tick_accounting) )
{
pt->pending_intr_nr = 1;
- pt->scheduled = now + pt->scheduled;
+ pt->scheduled = now + pt->period;
}
else
{
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home