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: Sun, 25 Sep 2005 11:09:43 +1000
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Sun, 25 Sep 2005 01:07:18 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <eaf0ac7e68e186851be1692632f24472@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> <1127433079.2722.24.camel@xxxxxxxxxxxxxxxxxxxxx> <eaf0ac7e68e186851be1692632f24472@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2005-09-23 at 10:24 +0100, Keir Fraser wrote:
> 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?

Yes that was the plan, although see other mail, I now prefer not
allowing save during transactions at all to avoid this issue.

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

Yes.  Using TDB means it's now copying a single file, rather than a
whole directory tree, but if someone puts in enough domains in the store
it will become a problem and we'll need a more sophisticated
implementation.  It would be a fun problem to work on, but I don't think
I can justify spending cycles on it yet: I can create around 10,000
domain-style directories in the store on my laptop in 22 seconds (using
10,000 separate transactions).

The advantage of the "whole copy" approach are simplicity and
robustness: if you SIGKILL xenstored your chances of recovery are
excellent, as commit is done as a rename(2).

Cheers!
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman


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