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

[Xen-devel] Re: Power aware credit scheduler

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: [Xen-devel] Re: Power aware credit scheduler
From: Emmanuel Ackaouy <ackaouy@xxxxxxxxx>
Date: Thu, 19 Jun 2008 15:09:16 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Thu, 19 Jun 2008 06:09:43 -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=KCQhs5qRjfF8chUE0uvZevWHzu1xpC3RP04KTU2nphk=; b=R1t1y4YIAnO9N3kd4G+2FzeGkrWLHuTYrHfyHm6/3L/aGfYSmbEZ3rUXUb6urUmirU iApLJGEsJrBuavg3PbXwosiqQC52+gQOFT9nlx2Zfu2i60Q1Ndes8l991zfSDWwezzKz Lqpykz0IL5ujr02iD43y37AtYVdnTs1n89Hg8=
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=C0QP5Qdyxc2tBfdxUZVO0Ybj85DlqIE24jE9UdUTs7gZTG+nmX3iU8gUHF3da/VxYY 729fr0iPfvfefXg4UdbPPgWi4e6gvtb0zlcpQgg6sDrs1/zWk3st+/SMLTxTqQzNn9JS p4oWeacFumYyWZVhP04ieYCNMTFTN3sUyAqVA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D9444@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Kevin.

I'm glad you're looking at this. There are a bunch of interesting
areas to look at to improve scheduling on large hierarchical
systems. The idle loop is at the center of most of them.

On Jun 19, 2008, at 6:51 , Tian, Kevin wrote:
a) when there's more idle cpus than required

a.1) csched_cpu_pick
        Existing policy is to pick one with more idle neighbours,
to avoid shared resource contention among cores or threads.
However from power P.O.V, package C-state saves much more
power than per-core C-state vehicle. From this angle, it might be
better to keep idle package continuously idle, while picking idle
cores/threads with busy neighbours already, if csched_private.
power is set. The performance/watt ratio is positively incremented
though absolute performance is kicked a bit.

Regardless of any new knobs, a good default behavior might be
to only take a package out of C-state when another non-idle
package has had more than one VCPU active on it over some
reasonable amount of time.

By default, putting multiple VCPUs on the same physical package
when other packages are idle is obviously not always going to
be optimal. Maybe it's not a bad default for VCPUs that are
related (same VM or qemu)? I think Ian P hinted at this. But it
frightens me that you would always do this by default for any set
of VCPUs. Power saving is good but so is memory bandwidth


a.2) csched_vcpu_wake
        Similar as above, instead of blindly kick all idle cpus in
a rush, some selective knock can be pushed with power factor
concerned.

Yeah, you will need to rewrite the idle kick code. This can be
tricky because a CPU's idle state might change by the time it
processes a "scheduling IPI" and you need to be careful that
a runnable VCPU doesn't sit on a runqueue when there is at
least one idle CPU in the system.

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