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

[John L Griffin <jlg@xxxxxxxxxx>]

Andi, thanks for your comments.  Is your sole concern the potential 
complexity of an implementation?  Or perhaps that even if we built it, 
that there would not be much demand for fine-grained resource tracking? My 
thought along these lines is that Xen's business audience would be 
interested in this idea, though the consumer audience probably would not.

> Consider a xenblk request from different domains that gets merged into
> a single request by the elevator. Would you charge the time the driver
> spends processing that one to the one domain or the other? Or a xenblk
> write the is done in the background by the pdflushd daemons?

In this scenario, the most interesting answers are:

(a) charge both (double-billing): if the "fairness" goal is that domain A 
be charged for whatever work had to be done by B while completing A's 
request, or
 
(b) charge neither: if the "fairness" goal is that a domain never be 
excessively charged for work it didn't specifically request.

My larger interest here is preventing domain A from acting maliciously or 
pathologically: the HP paper indicates that a domain A can easily consume 
a nontrivial amount (3-33%) of a service domain B's CPU.  This can be done 
with a continual series of small network requests (1 KB) that wouldn't be 
controlled by simply capping A's network utilization.

I am therefore concerned that a new domain C would be adversely affected 
by A's bad behavior.  Either domain B would perform poorly from C's 
perspective (less responsively? less predictably?), or (using the HP 
page-swapping counters) C would be unfairly charged for the unnecessary 
extra work initiated by A.

In the larger picture, I want to make it possible a service domain to be 
able to temporarily suspend its work on behalf of domain A.  In the 
context of using Xen in hosting environments, tracking the finer-grained 
resource consumption & making instantaneous scheduling decisions based on 
that will perhaps help meet stronger objectives of the host (enforcing 
service-level agreements) and the customer (accurate billing, isolation).

It's a valid concern that this scheme could end up being quite 
complicated, which I agree would severely limit any usefulness of the 
idea.  Perhaps a middle ground is to not aim for true cycle-accuracy, and 
therefore to err on the side of not allocating 100% of domain B's resource 
usage to guest domains.

JLG


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel