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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home