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] Re: [PATCH] Re: cs:21768 causes guest spend more time on

To: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Re: cs:21768 causes guest spend more time on boot up
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 19 Jul 2010 13:30:15 +0100
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "Zhang, Jianwu" <jianwu.zhang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Xu, Jiajun" <jiajun.xu@xxxxxxxxx>
Delivery-date: Mon, 19 Jul 2010 05:30:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C86A028E.1AF9E%keir.fraser@xxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsnPJZh26QjCjEITnG3FArGqLuJvQAAL+nYAAAzabw=
Thread-topic: [Xen-devel] Re: [PATCH] Re: cs:21768 causes guest spend more time on boot up
User-agent: Microsoft-Entourage/12.24.0.100205
On 19/07/2010 13:24, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> Ah, so it does.  I assumed it was the kernel because that's all that
>> changed on my test box since I last tested this stuff.  I'm using the C
>> xenstored and its code looks like it should work fine with the page
>> getting zeroed under its feet.  I'll dig further.
> 
> Thanks. The revised patch might be acceptable, but if possible we're better
> off relying on undocumented xenstored behaviour than domU frontend behaviour
> since the former we have full control over (albeit we now have two daemons
> to consider). Really nice would be some kind of explicit reset command or
> protocol, but in this context since there are no watches or pending requests
> or anything, I guess whacking the xenstore page is sufficient engineering
> effort.

And, yes, I agree it looks like the existing code should just work. The C
xenstored, at least, doesn't cache ring indexes.

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>