> I understand that ticks too close together causes
> time to move faster, but I thought your policy ensured
> that ticks were never delivered too close together.
> So I was surprised to see that time was moving faster
> rather than slower.
ok. Send me the debug info and I'll try to figure out
what's going on.
thanks,
Dave
-----Original Message-----
From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
Sent: Thu 6/12/2008 10:21 PM
To: Dave Winchell; Keir Fraser; xen-devel
Cc: Ben Guthro
Subject: RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
Hi Dave --
I understand that ticks too close together causes
time to move faster, but I thought your policy ensured
that ticks were never delivered too close together.
So I was surprised to see that time was moving faster
rather than slower.
Dan
-----Original Message-----
From: Dave Winchell [mailto:dwinchell@xxxxxxxxxxxxxxx]
Sent: Thursday, June 12, 2008 6:39 PM
To: dan.magenheimer@xxxxxxxxxx; Keir Fraser; xen-devel
Cc: Ben Guthro; Dave Winchell
Subject: RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
Hi Dan,
> Another theoretical oddity... if you are always delivering
> timer ticks "late", fewer than the nominal 1000 ticks/sec
> should be being received. So then why is guest time actually
> going faster than an external source?
With a guest that computes missed ticks, and is not dealing
with fractional ticks when the interrupts are closer than
a period:
If you send several interrupts farther apart than period and then
send one closer than period, the guest gains a tick. With this
fact you can have fewer than the expected number of interrupts
and be gaining time.
With one that expects the right number of interrupts (Windows)
delivering fewer than expected makes the guest run slow.
-Dave
-----Original Message-----
From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
Sent: Thu 6/12/2008 6:05 PM
To: Dave Winchell; Keir Fraser; xen-devel
Cc: Ben Guthro
Subject: Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
(Going back on list.)
OK, so looking at the updated patch, hpet_avoid=1 is actually
working, just reporting wrong, correct?
With el5u1-64-hvm and hpet_avoid=1 and timer_mode=4, skew
is under -0.04% and falling. With hpet_avoid=0, it looks
about the same. However both cases seem to start creeping
up again when I put load on, then fall again when I remove
the load -- even with sched-credit capping cpu usage. Odd!
This implies to me that the activity in the other domains
IS affecting skew on the domain-under-test. (Keir, any
comments on the hypothesis attached below?)
Another theoretical oddity... if you are always delivering
timer ticks "late", fewer than the nominal 1000 ticks/sec
should be being received. So then why is guest time actually
going faster than an external source?
(In my mind, going faster is much worse than going slower
because if ntpd or a human moves time backwards to compensate
for a clock going faster, "make" and other programs can
get very confused.)
Dan
> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> Sent: Thursday, June 12, 2008 3:13 PM
> To: 'Dave Winchell'
> Subject: RE: xen hpet patch
>
>
> One more thought while waiting for compile and reboot:
>
> Am I right that all of the policies are correcting for when
> a domain "A" is out-of-context? There's nothing in any other
> domain "B" that can account for any timer loss/gain in domain
> "A". The only reason we are running other domains is to ensure
> that domain "A" is sometimes out-of-context, and the more
> it is out-of-context, the more likely we will observe
> a problem, correct?
>
> If this is true, it doesn't matter what workload is run
> in the non-A domains... as long as it is loading the
> CPU(s), thus ensuring that domain A is sometimes not
> scheduled on any CPU.
>
> And if all this is true, we may not need to run other
> domains at all... running "xm sched-credit -d A -c 50"
> should result in domain A being out-of-context at least
> half the time.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home