All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dan Magenheimer" <dan.magenheimer@oracle.com>
To: Dave Winchell <dwinchell@virtualiron.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	Ben Guthro <bguthro@virtualiron.com>,
	xen-devel <xen-devel@lists.xensource.com>
Cc: "dan.magenheimer@oracle.com" <dan.magenheimer@oracle.com>
Subject: Isolation and time
Date: Fri, 13 Jun 2008 11:53:26 -0600	[thread overview]
Message-ID: <20080613115326796.00000057128@djm-pc> (raw)
In-Reply-To: <B99564216C25704085A82B41C46DD3427B060A@exchange.katana.local>

(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@virtualiron.com]
Sent: Thursday, June 12, 2008 4:14 PM
To: dan.magenheimer@oracle.com
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@oracle.com]
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
>

       reply	other threads:[~2008-06-13 17:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <B99564216C25704085A82B41C46DD3427B060A@exchange.katana.local>
2008-06-13 17:53 ` Dan Magenheimer [this message]
2008-06-13 18:49   ` Kernel printk timestamps and walltime drift Roger Cruz
2008-06-13 19:47     ` Keir Fraser
2008-06-13 20:10       ` Roger Cruz
2008-06-13 20:31         ` Keir Fraser
2008-06-13 20:06     ` Dan Magenheimer
2008-06-13 21:05       ` Roger Cruz
2008-06-13 21:21         ` Dan Magenheimer
2008-06-13 21:36           ` Keir Fraser
2008-06-13 22:02             ` Roger Cruz
2008-06-13 22:09               ` Keir Fraser
2008-06-13 19:38   ` Isolation and time Keir Fraser
2008-06-14  2:20     ` Dan Magenheimer
2008-06-14  8:59       ` Keir Fraser
2008-06-14 15:16         ` Dan Magenheimer
2008-06-14 15:25           ` Keir Fraser
2008-07-01  0:22             ` Dan Magenheimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080613115326796.00000057128@djm-pc \
    --to=dan.magenheimer@oracle.com \
    --cc=bguthro@virtualiron.com \
    --cc=dwinchell@virtualiron.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.