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


Re: [Xen-devel] Re: Fine-grained proxy resource charging

To: lucy@xxxxxxxxxxxxxxxx, jlg@xxxxxxxxxx
Subject: Re: [Xen-devel] Re: Fine-grained proxy resource charging
From: Lucy Cherkasova <lucy@xxxxxxxxxxxxxxxx>
Date: Thu, 25 Aug 2005 15:02:40 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 25 Aug 2005 21:57:21 +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
Hi John,

Here are a few comments to your  yesterday message.

> Perhaps a slightly longer-term view of performance 
> isolation is most appropriate here: assume two time quanta, Q1 and Q2, 
> where Q1 immediately precedes Q2.  Assume A has already used up its entire 
> resource allocation during Q1.  Now, if B unwittingly performs a service 
> for A during Q1 (say, accepting and processing packets from the network), 
> then perhaps A's Q2 allocation could be preemptively charged.

Yes, one can design different policies for dealing with a situation described 

> On a related tangent, did you and Rob do any finer-grained analysis of 
> which software components were generating the bulk of the high overheads 
> in dom0?  E.g., was it kernel time or user time; which kernel components 
> were the big offenders, etc.?  Perhaps if only a small number of 
> components are responsible for the bulk of the overhead, we can more 
> easily solve the more-accurate accounting & isolation problem by focusing 
> on only those components.

As I've mentioned in the previous message, we are working on more detailed 
accounting and instrumentation. Eventually, we plan to release it as an 
extension to the performance monitoring and profiling tool which is already 
available (xen-devel post "Yet another Xen performance monitoring tool" 
on 2005-08-18).



Xen-devel mailing list