WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] /proc/xen/xenbus supports watch?

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] /proc/xen/xenbus supports watch?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 23 Sep 2005 10:24:38 +0100
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Fri, 23 Sep 2005 09:17:32 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127433079.2722.24.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5d7aca9505090801025f3d5771@xxxxxxxxxxxxxx> <3d8eece205090803381b818f18@xxxxxxxxxxxxxx> <1126226609.25110.3.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091302422ac74f77@xxxxxxxxxxxxxx> <1126657264.7896.20.camel@xxxxxxxxxxxxxxxxxxxxx> <1126689530.4415.10.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091405555a2871fc@xxxxxxxxxxxxxx> <1126748390.12119.33.camel@xxxxxxxxxxxxxxxxxxxxx> <aad156145bec3bd706ef69c0e96341a7@xxxxxxxxxxxx> <1126945564.29203.116.camel@xxxxxxxxxxxxxxxxxxxxx> <bf4f0a8e8b96fd1ac2701daa78ca52c6@xxxxxxxxxxxx> <1127088661.23870.47.camel@xxxxxxxxxxxxxxxxxxxxx> <d7335251fd831e43f944d94e22da3878@xxxxxxxxxxxx> <1127214064.2656.45.camel@xxxxxxxxxxxxxxxxxxxxx> <61d8a8d77f6cbe2402b6a05810bd9447@xxxxxxxxxxxx> <1127355755.7567.24.camel@xxxxxxxxxxxxxxxxxxxxx> <4f7ac507bdbff3eafe3d0aaba1446e41@xxxxxxxxxxxx> <1127433079.2722.24.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 23 Sep 2005, at 00:51, Rusty Russell wrote:

Which is why I am pondering a bundle/unbundle interface for
transactions, so we can migrate them with the domain.  Summary:

How do you guarantee consistency of the migrated transaction? It holds no locks or anything on the values it has read while it is not running, so they could change under its feet?

Correctness-wise, it sounds to me as though bundle/unbundle has the same correctness guarantees as drop all writes, ENOENT on reads, and EAGAIN on commit.

Or is the bundling simply so that you can continue to feed consistent snapshotted values to the transaction from its 'shadow store', even though it is ultimately a doomed transaction?

Do xenstored's performance problems stem from copying the store for every transaction?

 -- Keir


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