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/
Home Products Support Community News


Re: [Xen-devel] [RFC] use event channel to improve suspend speed

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] use event channel to improve suspend speed
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 11 May 2007 07:55:45 +0100
Delivery-date: Thu, 10 May 2007 23:52:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070510230005.GA17705@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceTmWXEpHPvjv+MEduD4gAWy6hiGQ==
Thread-topic: [Xen-devel] [RFC] use event channel to improve suspend speed
User-agent: Microsoft-Entourage/
On 11/5/07 00:00, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:

> It would be interesting to know what aspect of the xenstore interaction
> is responsible for the slowdown. In particular, whether it is a fundamental
> architectural constraint, or whether it is merely due to the poor performance
> of the current impl. We already know from previous tests that XenD impl of
> transactions absolutely kills performance of various XenD operations due to
> the vast amount of unneccessary I/O it does.
> If fixing the XenstoreD transaction code were to help suspend performance
> too, it might be a better option than re-writing all code which touches
> xenstore. A quick test of putting /var/lib/xenstored on a ramdisk would
> be a way of testing whether its the I/O which is hurting suspend time.

Yes. We could go either way -- it wouldn't be too bad to add support via
dynamic VIRQ_DOM_EXC for example, or add other things to get xenstore off
the critical path for save/restore. But if the problem is that xenstored
sucks it probably is worth investing a bit of time to tackle the problem
directly and see where the time is going. We could end up with optimisations
which have benefits beyond just save/restore.

 -- Keir

Xen-devel mailing list