On Sun, 2005-09-25 at 12:33 +0100, Keir Fraser wrote:
> On 25 Sep 2005, at 12:02, Keir Fraser wrote:
>
> > Yeah, I can live with this, although: What about multiple transactions
> > within the kernel? Do you plan to continue serialising them (e.g., on
> > a waitqueue)? An advantage of mux/demux would be that concurrent
> > kernel transactions could easily use the same mechanism. Your scheme
> > places restart mechanisms in user space, so they're out of reach for
> > kernel transactions.
We already have the mechanism: xenbus_lock. I don't think we want to go
for parallelism within the kernel for xenstore comms: it'd be a fair
amount of pain for something which isn't exactly speed critical. Like
Andrew said, I can't transactions getting significantly longer.
> Also, page-per-connection won't entirely avoid sharing of
> state/resource in xenstored. At some point we'll want to add per-domain
> access policy, and space/bandwidth quotas (to prevent DoS). All of
> those must be shared between the multiple connections of a domain -- so
> the separate connections aren't as independent as you might like.
We already have a permissions model based on domid (although not
actually enforced due to a bug: we can fix this with one line but will
require xend fixups I imagine). Space quotas will have to be by ID,
too, not by the connection(s) which created them: in the case of
migration, the store will be recreated by the tools, but should still be
counted against the ID which owns them. So even if we multiplexed all
the connections together for one domain they would still have to be
separate.
Bandwidth quotas are and interesting idea: I was thinking of a dumb
fairness scheme. We almost do this: we rotate the list of connections,
but there's a FIXME about the unfair way we service domain pages. Or we
could just measure the time we spend servicing each connection, and put
the slowest ones at the tail... (socket connections would be immune,
since we trust dom0 tools). I haven't thought too hard about it.
Thanks, I'll update the TODO file...
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home