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 16:46:27 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 24 Feb 2005 21:48:20 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <421E3C6C.2070507@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
Oops, I indeed misread your patch -- my mistake.

However, I'm concerned that we're missing something bigger.  This is my 
understanding of what the BLOCKED flag (and the surrounding code) means:

1. The guest OS calls HYPERVISOR_block() (thus setting the BLOCKED flag) 
whenever it wants to yield the processor because it's waiting for an 
event.

2. This blocking can happen anytime -- including after the guest OS has 
been running for quite some time.

3. All the "event_pending(prev)" check in __enter_scheduler() is for is to 
say "whoops, an event arrived in the time between when the guest OS 
blocked & right now, so I should clear the BLOCKED flag."  This is so the 
domain can be rescheduled at the scheduler's earliest discretion (possibly 
immediately).

If these are true, then the original code was correct -- "prev->cpu_time" 
should be updated during any call to the __enter_scheduler() function, 
regardless of the state of the BLOCKED flag.

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 
domain improperly getting rescheduled immediately, or an improper 
modification of the prev->lastschd counter, or the "if (prev == next)" 
optimization [later in __enter_scheduler()] leaves out some crucial 
accounting, or...?

JLG



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

<Prev in Thread] Current Thread [Next in Thread>