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