From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Warfield Subject: Re: /proc/xen/xenbus supports watch? Date: Thu, 22 Sep 2005 18:01:49 -0700 Message-ID: References: <5d7aca9505090801025f3d5771@mail.gmail.com> <1126945564.29203.116.camel@localhost.localdomain> <1127088661.23870.47.camel@localhost.localdomain> <1127214064.2656.45.camel@localhost.localdomain> <61d8a8d77f6cbe2402b6a05810bd9447@cl.cam.ac.uk> <1127355755.7567.24.camel@localhost.localdomain> <4f7ac507bdbff3eafe3d0aaba1446e41@cl.cam.ac.uk> <1127433079.2722.24.camel@localhost.localdomain> Reply-To: Andrew Warfield Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1127433079.2722.24.camel@localhost.localdomain> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Rusty Russell Cc: xen-devel List , Steven Hand , Christian Limpach List-Id: xen-devel@lists.xenproject.org Rusty, Can you explain once again why you think that migrating in-progress transactions is the right thing to do? It seems to me that our transactions are generally pretty small, and I don't imagine them getting problematically bigger in the future. If client-side transaction code is already being written to expect failures and retry when they occur, what is the argument against blowing away in-progress transactions when you migrate. Given that the majority of current transaction code is to do with device drivers and you disconnect/reconnect those on migration anyway, why go through the extra work of adding complexity to migration? a. On 9/22/05, Rusty Russell wrote: > 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@lists.xensource.com > http://lists.xensource.com/xen-devel >