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] Power aware credit scheduler

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Power aware credit scheduler
From: Emmanuel Ackaouy <ackaouy@xxxxxxxxx>
Date: Thu, 19 Jun 2008 17:40:04 +0200
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Thu, 19 Jun 2008 08:40:44 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=jJT+09Or3vv2nz4qupP3Ia3QWqgNCL4SXIgGW8YhrI0=; b=V3SBvmTed7kd4xMVP3urC0qwnbHe5vZBub76p3rEf5nkV0+d3fAn22Hl+cdIMSYXa+ SqbaBZKSRMBLjcbtIlEymV9BzeukInhNPiISL2BfiM1kEyruSVoNZ1S40BBax2oEEIfb vPiFsnf2okOAUKl2CwFkFeWZp7r61pBaUM76M=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=JKxz3S/MbfllCDkGOFJNKz6swFEVO6deezJvU00w3FSHaR7xiLoYONG7yHw3N9dLuS hw/wSGZ5q1XZDsSiIVIaZbxhiASyNF7GOWPCmd3i3qGtlRFWWdHD1zZadQ1O3ydUk/pn +opRVaCmZJild9jRnT2Bm8SgmZprSyh032vgA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <DD74FBB8EE28D441903D56487861CD9D30B14D7D@xxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D9444@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D30B14407@xxxxxxxxxxxxxxxxxxxxxx> <D470B4E54465E3469E2ABBC5AFAC390F024D9452@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <DD74FBB8EE28D441903D56487861CD9D30B14D7D@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Jun 19, 2008, at 15:30 , Ian Pratt wrote:
That's OK -- it's fine to account in arrears, and doing so will have the
right influence on how we schedule things in the future.  That's why
it's important to move from tick accounting to absolute.

I actually still don't agree it's important to move from tick accounting
to absolute. CPU wall clock time is an approximation of service to
start with. From the point of view of basic short term fairness and
load balancing, tick based accounting works well and is simple to
scale.

Accounting for shared resources of physical CPUs makes sense,
be it caches or memory buses (or the pipeline in the hyperthread
case). But you can't really do that precisely: 2 CPUs may share a
memory bus, but perhaps one of them is compute bound out of its
L1 cache. What is the point of precisely measuring wall clock CPU
time if you're then going to multiply that number by some constant
that may or may not reflect the real impact of resource sharing in
that case?

IMO, the more pressing problem is to approximately account for
shared physical resources and scale the cpu_pick() and cpu_kick()
mechanisms to improve efficiency on medium and large hierarchical
systems. It's probably ok to approximate the cost of sharing physical
resources using reasonable constants (ie 0.65 when co-scheduled
on hyperthreads).

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