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: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Calculating real cpu usage of Xen domains correctly!
From: John L Griffin <jlg@xxxxxxxxxx>
Date: Thu, 24 Feb 2005 08:56:43 -0500
Cc: aliguori@xxxxxxxxxx
Delivery-date: Fri, 25 Feb 2005 12:36:53 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <421D458D.2090906@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
> I think what's happening is that cpu_time is being updated even if the 
> domain is blocked. Looking in xen/common/schedule.c:__enter_scheduler(), 

> the update to cpu_time is still being updated even if SCHED_OP(do_block, 

> prev) is invoked.

My quick perusal of the current xeno-unstable code suggests that this 
SCHED_OP call is a null call.  The SCHED_OP macro attempts to call the 
"do_block" function pointed to in the "struct scheduler sched_bvt_def" 
array, but this function pointer is never initialized, so it just does a 
NOP.

It appears that what your patch does is limit when cpu_time gets updated, 
such that the time only gets updated when the exec_domain is in the 
BLOCKED state:

    if ( test_bit(EDF_BLOCKED, &prev->ed_flags) )
        prev->cpu_time += now - prev->lastschd;
    }

But what does the BLOCKED state mean?  This isn't well documented: "Block 
the currently-executing domain until a pertinent event occurs."  The 
BLOCKED flag appears to be set by the "SCHEDOP_block" hypervisor call, 
which is triggered from the guest domains inside the xen_idle() call. Here 
is some code from xen_idle in process.c:

        } else if (set_timeout_timer() == 0) {
                /* NB. Blocking reenable events in a race-free manner. */
                HYPERVISOR_block();
        } else {
                local_irq_enable();
                HYPERVISOR_yield();
        }

What this seems to be saying (in regard to your patch working) is that the 
cpu_time is updated when the domain relinquishes the CPU by block()ing, 
but cpu_time doesn't get updated if it relinquishes the CPU by yield()ing.

I wonder why this works.  Is anyone familiar with block() vs yield(), that 
could lend some insight into what's going on? 

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>