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: Wed, 24 Aug 2005 09:35:04 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 24 Aug 2005 16:29:40 +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,

Some comments to your last message:

> > I/O bandwidth is a natural extension for resource accounting and can
> > be addressed as well.
> Agreed.  An interesting extension of this example: what if a non-I/O 
> privileged service domain B (say, a domain that provides a object 
> encryption service) must sometimes perform some network I/O through a 
> third domain (say, downloading a new encryption algorithm from an external 
> source) in order to continue servicing A's requests?  In this case, it 
> will need to be possible for B to transitively specify on whose behalf the 
> third-party work is being performed.

I think it might depend on the goal: if the goal is  an "accounting",
i.e. charging the domain  for the resources  it used, then one still can use
pair-wise accounting schema, and should be able to derive the transitive 
charging from the higher level relationships/agreements, or again use some
reasonable approximation (split the extra charge among all the parties using 
this encription service). Otherwise it becomes too complex (need to track  the
resource usage on the application level, and it seems beyond the Xen reach).

> However, I'd already rejected the idea, and decided to concentrate on 
> alternate/finer-grained/internal-to-B approaches, for several reasons:
> - Preventing DoS.  The count-page-exchanges scheme is good for CPU 
> accounting, especially since it can be done with an unmodified B. However, 
> in the context of actively rate-limiting A's resource consumption (perhaps 
> by delaying or failing the page exchanges) it wouldn't work, since by the 
> time B invokes a grant table operation it's too late -- B has already been 
> affected.

You are right, the DOS prevention and performance isolation require
a more detailed resource usage accounting. The problem is hard:
once the packet is processed by a driver (in B) and it is known which domain 
it is destined the largest potion of the work is done already... Even if 
the driver domain (B) decides do not  deliver this packet to a destination 
domain  A (due to high resource consumption on behalf of A), it can be 
somewhat late to react: B already has used a lot of resources for "half" 
processing packets on behalf of A...

> > The problem gets
> > much harder and more complex when there are different drivers hosted
> > by the same driver domain.
> Could anybody comment on the current status of breaking dom0 into multiple 
> single-function service domains, and/or not having a driver domain hosting 
> multiple drivers?  I'm not caught up on Xen's current events, pun 
> intended.

Yes, I would join in asking the same question: how to get a working 
configuration for multiple driver domains each hosting a single device driver?


> Maybe it'd be 
> possible to split a driver domain into a group of cooperating 
> mini-domains, that collectively accomplish the same purpose but are 
> independently scheduled?  Each mini-domain would service exactly one 
> A-type domain.  (How bad are context switches in ring 1...maybe not too 
> bad, so the main challenge would be architecting the mini-domains.)  I'd 
> be happy to join in (from a distance) on any continuing whiteboard 
> discussions you have along these lines.

I'm not sure whether this can be done, it seems that it is impossible to split
the driver domain in the "mini-domains" you describe, unless you have a separate
I/O device per each A-type domain (i.e. the devices are not shared).

Best regards, Lucy

Xen-devel mailing list