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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] /proc/xen/xenbus supports watch?
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Fri, 23 Sep 2005 09:51:19 +1000
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Thu, 22 Sep 2005 23:48:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4f7ac507bdbff3eafe3d0aaba1446e41@xxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2005-09-22 at 10:35 +0100, Keir Fraser wrote:
> Whatever, the client probably needs the code to realise that a bad 
> thing has happened and to take appropriate action whichever strategy we 
> go for. I suspect they are equivalent complexity for clients.

I think you've summed it up well.  Of these two I'm leaning towards
EAGAIN (which the client can turn into a fake success if they want).
But both are subtle and kinda icky.

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

1) Easy to do at the moment: we already snapshot the entire store for
transactions, so we can just bundle/unbundle that.  We need
globally-unique transactions IDs, but that's fairly simple.
2) Each domain adds roughly 5k to the store (this will increase, say
10k).  This means migrating off a node with 100 domains means adding 1M
to the data we have to send *per transaction*.
3) The store compresses extremely well (~800 bytes per domain), so we
could trivially get it down to 160k/transaction in the 100 domain case.

You know I treasure simple APIs, and this makes the store API simpler
and so reduces subtle errors in future.

But is it worth the complexity?
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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