From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: Re: Isolation and time Date: Mon, 30 Jun 2008 18:22:19 -0600 Message-ID: <20080630182219859.00000003744@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=-------3ba161263ba16126 Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Dave Winchell , Ben Guthro , xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format ---------3ba161263ba16126 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > Yes, I reckon that could work pretty well. > = > -- Keir I'm pretty sure the attached script when run in domain0 will generate an appropriately random CPU load on every domain0 vcpu. For each vcpu, it randomly eats CPU for a fraction of a second, then sleeps for the same amount of time, then repeats. Thus any timer-under-test domain should see random unscheduled intervals which hopefully occur at random fractions of its timer tick. I'll probably use this for future timer testing, so let me know if you see problems with this approach. Thanks, Dan P.S. May be dependent on RH-based dom0. > -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Saturday, June 14, 2008 9:25 AM > = > wrote: > = > > That's what I thought. Sorry to belabour, but > > that leads to one more question: > > > > If one were to put an appropriately random CPU-only load > > on every processor on domain0 (assuming domain0 runs > > on all physical processors), then this would presumably > > be sufficient to exercise a domain-under-test's time > > synchronization, correct? > = > Yes, I reckon that could work pretty well. > = > -- Keir ---------3ba161263ba16126 Content-Type: text/plain; name="dom0busy.sh" Content-Disposition: attachment; filename="dom0busy.sh" Content-Transfer-Encoding: base64 IyEvYmluL2Jhc2gKIyBkb20wYnVzeSAtIHJhbmRvbWx5IGJ1c2llcyBhbGwgZG9tMCB2Y3B1 cwojIGtlZXBzIGNwdSBidXN5IGZvciBhIGZyYWN0aW9uIG9mIGEgc2Vjb25kLCB0aGVuIHNs ZWVwcyBmb3IgdGhlIHNhbWU7IHJlcGVhdAojIHJ1biBpbiBkb21haW4wIGFzIHJvb3QsIGNh biBiZSBtb25pdG9yZWQgaW4gdG9wClRNUEZJTEU9YG1rdGVtcCAvdG1wL2RvbTBidXN5LlhY WGAgfHwgZXhpdCAxCigKY2F0IDw8J0VPRicKIyEvYmluL2Jhc2gKd2hpbGUgdHJ1ZTsgZG8K CVJBTkRPTT0kJCQoZGF0ZSArJVMpCglyMT0kUkFORE9NCglyMj0kUkFORE9NCglsZXQgbG9v cHM9IigkcjEqJHIyKSUxMDAwMCIKCXN0YXJ0PWBkYXRlICslcy4lTmAKCXdoaWxlIFsgJGxv b3BzIC1ndCAwIF07IGRvCgkJbGV0IGxvb3BzPSIkbG9vcHMtMSIKCWRvbmUKCWZpbj1gZGF0 ZSArJXMuJU5gCgllbGFwc2VkPWBlY2hvICJzY2FsZT0zOyAkZmluIC0gJHN0YXJ0IiB8IGJj IC1pcWAKCSNlY2hvIHNsZWVwaW5nIGZvciAkZWxhcHNlZCBzZWMKCS9iaW4vc2xlZXAgJGVs YXBzZWQKZG9uZSAmCkVPRgopID4gJFRNUEZJTEUKY2htb2QgK3ggJFRNUEZJTEUKbmNwdXM9 YHhtIGxpc3QgfCBncmVwIERvbWFpbi0wIHwgc2VkICdzLyAgKi8gL2cnIHwgY3V0IC1mNCAt ZCIgImAKZWNobyBCdXN5aW5nICRuY3B1cyBjcHVzCmxldCBuY3B1cz0iJG5jcHVzLTEiCndo aWxlIFsgJG5jcHVzIC1nZSAwIF07IGRvCgllY2hvIGJ1c3lpbmcgY3B1ICRuY3B1cwoJdGFz a3NldCAtYyAkbmNwdXMgJFRNUEZJTEUKCWxldCBuY3B1cz0iJG5jcHVzLTEiCmRvbmUKL2Jp bi9ybSAtcmYgJFRNUEZJTEUKCg== ---------3ba161263ba16126 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ---------3ba161263ba16126--