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] Sched planning: Ideal scheduler, and credit1

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Sched planning: Ideal scheduler, and credit1
From: Gaurav Somani <onlineengineer@xxxxxxxxx>
Date: Sun, 7 Jun 2009 10:22:55 -0700 (PDT)
Delivery-date: Sun, 07 Jun 2009 10:23:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0906050311p4e9720a6xc4983e2287d6982d@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a0906050311p4e9720a6xc4983e2287d6982d@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi George,

had a great and quite illustrative read. having some queries?



* Credit1, and why it doesn't work well for video

At a basic level, credit1 has two main priorities: UNDER and OVER.

 Credits are handed out every 30ms according to weight.  VMs that have
positive credits are classed at priority UNDER, and those with
negative credits are classed as OVER..............


>>> I have read in ongaro et al's (Schedulin I/O in Virtual machine
>>> monitors) paper that credits are handed over to domains after the sum of
>>> all the credits in the system goes negative. So that time will come
>>> after all the UNDER and BOOST domains complete their execution for the
>>> all credit time=30ms they have.



Credit1 has a strong probabilistic element.  Every 10ms a "tick" timer
fires.  When the tick happens, a full 10ms of credit is subtracted
from the currently running VM.  It relies on an element of randomness
to spread this charge appropriately over all active VMs.

However, if we divide credits over all VMs we have the following
problem: if some VMs are idle, then what will happen is that the
"active" VMs will spend most of their time in the "OVER" state, while
mostly idle VMs will spend all of their time in the "UNDER" state
accumulating more and more credits.  So credit1 attempts to
distinguish between two kinds of workloads:

* "active" workloads, which are competing for CPU, and need to have
  credit accounting done.

* "inactive" workloads, which use minimal cpu, and need no credit
  accounting.




>>>>>>How credit scheduler can identify the application it is running at
very first time. Please correct me if i m wrong. Where does credit scheduler
classify active and inactive workload? (in code)


The rules for determining whether a VM was "active" or "inactive" are
as follows:

Thanks
Gaurav Somani
-- 
View this message in context: 
http://www.nabble.com/Sched-planning%3A-Ideal-scheduler%2C-and-credit1-tp23885657p23913205.html
Sent from the Xen - Dev mailing list archive at Nabble.com.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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