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


[Xen-devel] Re: [PATCH 0 of 8] Remove static variables from xc_domain_{s

To: <rshriram@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 0 of 8] Remove static variables from xc_domain_{save, restore}.c
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Tue, 24 May 2011 18:02:57 +0100
Cc: Jim Fehlig <jfehlig@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Campbell <ian.campbell@xxxxxxxxxx>
Delivery-date: Tue, 24 May 2011 10:05:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTimp6NToYCX8q-Nfkd+eGJvuxEmt-Q@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <patchbomb.1306228466@xxxxxxxxxxxxxxxxxxxxxxxxx> <BANLkTimp6NToYCX8q-Nfkd+eGJvuxEmt-Q@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Shriram Rajagopalan writes ("[Xen-devel] Re: [PATCH 0 of 8] Remove static 
variables from xc_domain_{save, restore}.c"):
> I ll do it!!.. I have been waiting for this. Thanks a lot for
> cleaning up this chaff!  I was under the impression that this was
> some arcane legacy code that shouldnt be touched.

No, it's arcane legacy code that we have been gradually cleaning up

> One particular
> thing that I would like to do is to factor out the write functions
> (outbuf_*, noncached_write, ratewrite*, etc) into a separate file
> and make it sort of pluggable.

Do you have a particular use case fot that ?  Without a different set
of implementations I'm not sure that we need it to be pluggable.

> (selfish :P) I wanted to introduce a patch that would overlap outbuf
> flush operation and guest memory copy operation instead of the
> current model <flush,copy,flush,copy..>.  This might be helpful for
> both Remus and live migration of large domains.

But yes, if that produces a speedup, certainly.

>  Shriram, does this have any impact on Remus?

I think it should be OK but we should hear what Shriram has to say


Xen-devel mailing list