[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Isolation and time

(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

Comments?  My preliminary testing has been inconclusive.


-----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


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.


-----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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.