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

Re: [Xen-devel] Calculating real cpu usage of Xen domains correctly!

To: aliguori@xxxxxxxxxx
Subject: Re: [Xen-devel] Calculating real cpu usage of Xen domains correctly!
From: John L Griffin <jlg@xxxxxxxxxx>
Date: Thu, 24 Feb 2005 22:53:31 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 25 Feb 2005 15:31:35 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <421E5CE6.5040109@xxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
(Augh, sourceforge mail is driving me nuts; it lost an email exchange 
between Anthony and myself earlier & seems to have lost the included 
message below; who knows what other valuable messages were lost today? 
XenSource: get the new mail reflector going!)

Anothony, here are some ideas:

- Change the default scheduler in schedule.c to rrobin and/or atropos, to 
see if they exhibit the same problem.

- Create a new global variable "cputime_total" and keep track of the sum 
of all time intervals to make sure the value is sane:

    prev->cpu_time += now - prev->lastschd;
    cputime_total  += now - prev->lastschd;

- Lie about the value of "now - prev->lastschd": make it a constant 1ms 
per invocation of __enter_scheduler(), and use that to count the number of 
times each domain gets scheduled.

- Make "lastschd" a global variable, to test if the "prev" structure is 
getting overwritten somehow.

- Make the return type of get_s_time() and its child calls [in time.c] 
volatile, to make sure the return value of NOW() isn't getting 
unnecessarily cached.

- In lieu of printk()s on each scheduler entry, you could allocate a few 
pages of memory, use a signal to fill them up with timestamps & the 
results of the ops.do_schedule(now) call during your experiment, then 
printk() the pages out postmortem.

JLG


Anthony Liguori wrote:

> John L Griffin wrote:
> 
> >However, I'm concerned that we're missing something bigger.  This is my 

> >understanding of what the BLOCKED flag (and the surrounding code) 
means:
> > 
> >
> You may be correct here.  The thing that leads me to believe that is the 

> following.  When I first start up domain-0, with no domain-U's running, 
> the numbers for domain-0 seem right.  Domain-0's usage jumps up to 100% 
> after I create a domain-U.  Once I've reached this point, it pretty much 

> stays that way.
> 
> It makes me think someone something's triggering this behavior.
> 
> >Which makes me wonder if something is seriously misbehaving to cause 
the 
> >weird CPU usage totals you're seeing -- like a yield()ed or block()ed 
> > 
> >
> Do you have any ideas (or anyone else for that matter) on how to 
> approach this?  I'm afraid the impact of putting printk's in there would 

> be too great.  How does one typically debug scheduler issues?
> 
> I'm willing to spend some cycles looking into this.
> 
> Regards,
> Anthony Liguori



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel