[Xen-devel] Re: Isolation and time

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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