[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Power aware credit scheduler


  • To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
  • 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
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.