OK, I guess I can buy that. Running real domains
will cause more scheduling "artifacts": domain A
will likely run more frequently for shorter periods
of time than if sched-credit-capped with no other
domains running. And more frequent "spurts" could
result in more fractional ticks in domain A that
potentially could get lost or miscounted.
But is there anything else?
Suppose the credit scheduler were modified to
optionally schedule random "spurts" when the
sum of caps was less than the total available
CPU. Would you then expect the results to be
essentially the same?
And, on a N pcpu machine, if a single "interference
domain" was run with N threads that randomly absorb
much/most of each VCPU (but do no I/O), would that
be just as good as running multiple interference domains?
I'm not just wondering this for curiosity. All of
my recent hpet testing used multiple domains that
ate CPU, but did no I/O.
Thanks,
Dan
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Friday, June 13, 2008 1:39 PM
> To: dan.magenheimer@xxxxxxxxxx; Dave Winchell; Ben Guthro; xen-devel
> Subject: Re: Isolation and time
>
>
> 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