On Saturday, December 31, 2005 1:53 AM, Keir Fraser wrote:
> On 31 Dec 2005, at 05:38, Cihula, Joseph wrote:
>
>> However, when the watch bookkeeping is combined with the transaction
>> bookkeeping (which is already there) this is a lot of duplication
>> with what xenstored already has to do for each connection. I'm
>> wondering if it wouldn't be better to add a sub-connection id to
>> xenstored and xenbus so that each xenbus client would be seen by
>> xenstored as a separate (sub)connection. Then watches and
>> transactions would not need any special code in xenbus, as xenstored
>> would handle the tracking and cleanup.
>>
>> This method would either need to change the xenstore wire protocol or
>> co-opt the req_id field (which doesn't seem to be used). While some
>> additional code would have to be added to xenstored, I think that a
>> fair amount of code (and many synchronization locks/mutexes) in
>> xenbus could be removed.
>
> How about add a new command XS_NEW_CONNECTION, taking a grant
> reference
> and an event channel? This would then set up a new inter-domain event
> channel and messaging memory page, and then commands would no longer
> go via the kernel at all.
>
> One drawback is it would then be very hard for the kernel to tell
> whether any xenstore transactions are in progress in user space. This
> is a problem since transaction state is not copied during
> save/restore.
> Either that needs to happen, or transactional xenstore code needs to
> handle 'spurious' failures at any point in a transaction (handle
> EAGAIN on any transactional read/write, not just on commit).
>
> -- Keir
It seems like this would add a lot of overhead. Xenstore commands are
typically only a couple hundred bytes and since they are synchronous
(per client and excluding watches), this would leave a lot of the page
unused. Moreover, for transient clients, such as xenstore-{read, write,
rm}, the extra setup/teardown would also add to the cost.
Joe
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home