Whether machine load can affect an HVM guest's time synchronisation really
depends on how the guest OS manages time. If it depends on 'timely' timer
ticks on a specific VCPU, for example, then there's probably a limit to what
we can do. Luckily it seems that many kernels are fairly robust to missing
ticks however -- using ticks just to kick off queued work and to update
system/wall-time stamps. If you want to do a really thorough testing job I
don't think you can ignore the multi-domain case.
(1) and (2) below should probably behave similarly, but I'd expect that (2)
might result in more regular scheduling/descheduling of the domain under
test than (1) where the other domains run I/O workloads (and hence have
irregular CPU demand).
-- Keir
On 13/6/08 18:53, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:
> (Moving from offlist discussion.)
>
> I'm interested in opinions... Assume there are four
> single vcpu domains A, B, C, D, running on a 2-CPU
> physical machine. We wish to test for time skew on
> domain A. Assuming B, C, and D are all running
> some workload that attempts to fully saturate the
> (single) cpu.
>
> 1) Should the affect on domain A be essentially the
> same regardless of what load (e.g., compile,
> lmbench, or just "while(1);") is running in
> B, C, and D?
> 2) Should "xm sched-credit -d A -c 50" have the
> same result (e.g. no other domains need be run)?
>
> If the load on other domains can affect time skew on
> domain A, this raises isolation questions. And
> it makes time skew testing much harder (What loads
> and real-customer situations can cause more skew?)
>
> If the load on other domains canNOT affect time skew
> on domain A, testing for time skew becomes a lot
> easier. (Use sched-credit instead of launching multiple
> domains.)
>
> Comments? My preliminary testing has been inconclusive.
>
> Dan
>
> -----Original Message-----
> From: Dave Winchell [mailto:dwinchell@xxxxxxxxxxxxxxx]
> Sent: Thursday, June 12, 2008 4:14 PM
> To: dan.magenheimer@xxxxxxxxxx
> Cc: Dave Winchell
> Subject: RE: xen hpet patch
>
>
> Dan,
>
> Usually forcing "out-of-context" is more stressful.
> I think doing it with real domains under load is more realistic.
> However, the scheduling thing may be equivalent - I just haven't
> looked into it or thought about it.
>
> thanks,
> Dave
>
>
> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> Sent: Thu 6/12/2008 5: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.
>
> Dan
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home