WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Isolation and time

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: Isolation and time
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 13 Jun 2008 20:38:47 +0100
Delivery-date: Fri, 13 Jun 2008 12:38:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080613115326796.00000057128@djm-pc>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjM0Rhtsp0FqzEJQH+pTArFmFSulQACI1i0ACgZ8YAABMLO9A==
Thread-topic: Isolation and time
User-agent: Microsoft-Entourage/11.4.0.080122
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