From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: /proc/xen/xenbus supports watch? Date: Fri, 23 Sep 2005 09:51:19 +1000 Message-ID: <1127433079.2722.24.camel@localhost.localdomain> References: <5d7aca9505090801025f3d5771@mail.gmail.com> <3d8eece205090803381b818f18@mail.gmail.com> <1126226609.25110.3.camel@localhost.localdomain> <3d8eece205091302422ac74f77@mail.gmail.com> <1126657264.7896.20.camel@localhost.localdomain> <1126689530.4415.10.camel@localhost.localdomain> <3d8eece205091405555a2871fc@mail.gmail.com> <1126748390.12119.33.camel@localhost.localdomain> <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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4f7ac507bdbff3eafe3d0aaba1446e41@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel List , Steven Hand , Christian Limpach List-Id: xen-devel@lists.xenproject.org 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