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/
Home Products Support Community News


[Xen-devel] RE: Scheduler follow-up: Design target (was [RFC] Scheduler

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Scheduler follow-up: Design target (was [RFC] Scheduler work, part 1)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 16 Apr 2009 11:29:15 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Delivery-date: Wed, 15 Apr 2009 20:31:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0904140538u5834ce93t7118e570ac2d0fc3@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: <de76405a0904140538u5834ce93t7118e570ac2d0fc3@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm8/eVQUHfUiG2iThuVMSkzk5Hc9wBQai8w
Thread-topic: Scheduler follow-up: Design target (was [RFC] Scheduler work, part 1)
>From: George Dunlap
>Sent: 2009年4月14日 20:38
>Hey all,
>Thanks for the feedback; and, sorry for sending it just before a
>holiday weekend so there was a delay in writing up a response.  (OTOH,
>as I did read the e-mails as they came out, it's given me more time to
>think and coalesce.)
>A couple of high bits: This first e-mail was meant to lay out design
>goals and discuss interface.  If we can agree (for example) that we
>want latency-sensitive workloads (such as network, audio, and video)
>to perform well, and use latency-sensitive workloads as test cases
>while developing, then we don't need to agree on a specific algorithm

That looks fine to me, but latency-sentitive shouldn't be the only part
to be concerned. :-)

>* [Kevin Tian] How is 80%/800% chosen here?
>Heuristics.  80% is a general rule of thumb for optimal server
>performance.  Above 80% and you may get a higher total throughput (or
>maybe not) but it will be common for individual VMs to have to wait
>for CPU resources, which may cause significant performance impact.
>(I should clarify, 80% means 80% of *all* resources, not 80% of one
>cpu; i.e., if you have 4 cores, xenuse may report 360% of one cpu;
>but 100% of all resources would be 400% of one cpu.)
>800% was just a general boundary.  I think it's sometimes as important
>to say what you *aren't* doing as what you are doing.  For example, if
>someone comes in and says, "This new scheduler sucks if you have a
>load average of 10 (i.e., 1000% utilization)", we can say, "Running
>with a load average of 10 isn't what we're designing for.  Patches
>will be accepted if they don't adversely impact performance at 80%.
>Otherwise feel free to write your own scheduler for that kind of
>system."  OTOH, if a hosting provider (for example) says, "Performance
>really tanks around a load of 3", we should make an effort to
>accomodate that.

Got it. So one more interesting question is, how do you define a
''function reasonablely well'' under 800% utilization, any criteria?

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>