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

[John L Griffin <jlg@xxxxxxxxxx>]

> 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...

Interesting point.  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.

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.

------------------------------------------------------------------------

Andi's earlier comments have started me thinking more about the 
complexities involved in cycle-accurate accounting for service domains. 
For reference purposes (if we don't solve the problem now, perhaps someone 
else will in the future), here are the possible approaches I've come up 
with so far.  Does anyone have other approaches to add to the list?

1. Cycle-accurate accounting

  A. Ensure each service domain only performs work on behalf of a single 
client (a one-to-one mapping), and charge the client for the service 
domain's consumption.

  B. Ensure a service domain performs exactly the same amount of work for 
each client, and charge the client based on the number of requests it 
generates.

  C. Ensure each intradomain/OS-oriented protection mechanism [threads, 
processes] only performs work on behalf of a single client, as in 1A.

  D. For each thread/process that multiplexes its time among several 
clients, ensure that it identifies to the accounting/charging mechanism on 
which client's behalf it is performing the work.  This could be done by, 
for example, using system calls to explicitly affiliate and later 
disassociate with a particular domid.

  E. [Resource containers, Banga99.]  For each thread/process that 
multiplexes its time among several tasks (such as incoming packets, where 
each packet represents a task), ensure that it identifies to the 
accounting mechanism on which task it is currently operating.  Later, once 
a task is associated with the appropriate source or destination client, 
the charging mechanism applies the credits consumed by the task to the 
client.

2. Near-accurate accounting

  A. Measure a priori the average resources consumed per request (or per 
IPC), and charge the client based on the number of requests it generates.

  B. [Cherkasova05.]  Assign a proportional allocation of a service 
domain's resource consumption to clients, based on the number of requests 
(or IPCs) generated by each client.

  C. Assign weights to each request (or IPC) in 2B, to modify the 
assignment based on additional knowledge (such as the rate or frequency of 
requests, the magnitude of the IPC, or the [non]uniformity of a series of 
IPCs from the client).


At first glance the approach that makes the most sense is 1E, except that 
it would seemingly require substantial modifications to Linux and any 
user-level software in the service domain.  But maybe there's a way to 
leverage something like SELinux?  For example, by treating the flow of 
resources through a system the same way SELinux treats information flows.

JLG



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