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] Is anyone using the credit scheduler "cap" functionality

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Is anyone using the credit scheduler "cap" functionality?
From: Eric Windisch <eric@xxxxxxxxxxxx>
Date: Tue, 20 Jan 2009 16:40:25 -0500
Delivery-date: Tue, 20 Jan 2009 13:53:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090120195904.EAC89F41E8@xxxxxxxxxxxxxxxxxxx>
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: <20090120195904.EAC89F41E8@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>

I'm in the process of revising the credit scheduler design, and I'd
like to know how important it is to maintain the "cap" functionality
of the credit scheduler.  If you use it, or know of someone who does,
could you let me know?

If you don't know what it is, you probably aren't using it. :-)

Thank you George, for asking, before putting this into code ;-)

Yes, we use it at GrokThis.net for our Xen/VPS hosting services.  I believe this feature to be vitally important for us.  We sell, to the public, root access to our Xen guests.   I imagine that we have more guests per machine than is typical, as we must increase the NR_IRQS variable in the kernel (with two block devices per guest), although I know that Brian Carb at Unisys has stressed it more than I have, but only in a lab.

To the point, because we sell to the public, and because we have a fairly large number of guests per machine, we use the 'cap' functionality to assure that our systems run smoothly.   In this regard, the fact that we have many guests may be more important than the fact that we're selling to the public.  It is not uncommon for us to find guests which have been misconfigured in such a way that they peg the guest's available CPU.  This happens much more frequently than customers consuming this level of CPU naturally, but we do wish to limit those customers as well, based on a percentage according to the cost of their monthly plan.

Simply, by using caps, we can assure that abusive guests do not interfere with those that are more well-behaved.  Prior to implementing the caps, we would frequently receive complaints unless we vigilantly and manually  baby-sat the systems and resolved these situations.  After implementing, even customers not knowing we had made changes made remarks about improved performance.   Now, we can go through the systems on a weekly or even monthly basis and fix the "problem" guests without having to baby-sit.

The issues I've described are less of a concern as the ratio of guests to cpu cores reaches 1:1, but in environments where it is practical to have a larger ratio between these, the cpu cap can really make a big difference.   I understand that significant differences to the scheduler might possibly solve the problems I'm describing, but if such changes were made it would have to be throughly tested and proven before it replaced, on my systems, what is there currently.

--
Eric Windisch
GrokThis.net Internet Solutions
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel