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] Fine-grained proxy resource charging

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Fine-grained proxy resource charging
From: John L Griffin <jlg@xxxxxxxxxx>
Date: Mon, 22 Aug 2005 01:25:19 -0400
Cc: rob.gardner@xxxxxx
Delivery-date: Mon, 22 Aug 2005 08:31:37 +0000
Envelope-to: www-data@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/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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I am looking into how to charge a domain (say, domain "A") for the 
resources consumed by other service domains (say, B) on behalf of A.  For 
example, charging A for the CPU cycles consumed by the network I/O domain 
(B) as it processes packets produced or consumed by A.

The HP folks recently demonstrate a useful first step (see the Usenix 2005 
paper and the xen-devel post "Yet another Xen performance monitoring tool" 
on 2005-08-18): count the number of page swaps between A and B (as well as 
C and B, D and B, etc.) and use that to approximate how much of B's CPU 
usage should be assigned to A (and C, D, etc.)

I'm pursuing more cycle-accurate methods, in anticipation of non-dom0 
service domains that will do variable amounts of proxy processing, 
especially where the resources consumed (CPU, memory, I/O, larger 
primitives) are not correlated with the amount of interdomain traffic 
between A and B.  For example, a lightweight version of Resource 
Containers (Banga, OSDI 1999) or similar concepts.

The eventual goal would be for B itself to calculate and specify to Xen 
the amount of processing it does on behalf of A and other domains. Looking 
ahead, a possible next step is for Xen to expose to B whether or not A has 
already exceeded its periodic resource allocation, so any schedulers 
inside B can make smarter decisions: for example, not processing packets 
for A when A has temporarily exhausted its allocation.

There aren't many technical details yet; my objective here is to 
synchronize with anyone who's also been thinking about this particular 


Xen-devel mailing list