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] [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Wed, 01 Apr 2009 12:00:04 +0100
Cc: "andy@xxxxxxxxx" <andy@xxxxxxxxx>, Brendan Cully <brendan@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 01 Apr 2009 04:00:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5F90122.5516%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>
References: <C5F90122.5516%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2009-04-01 at 11:31 +0100, Keir Fraser wrote:
> On 01/04/2009 11:26, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> >> Could it be as simple as this? I can't remember what happens if
> >> unregister_xenbus_watch is called after the xenbus connection has been
> >> reset. Should we just free the guest structures without interacting
> >> with xenstore at the start of the resume method?
> > 
> > It may be possible to synchronise the watch handler with the
> > suspend/resume/cancel cycle without removing the watch, but that starts
> > to get complicated.
> Could we avoid any of this logic executing if there are no net accelerators?

The watch handler will try to load an accelerator if the configuration
changes, so even if there were no accelerators before the suspend,
unless you can prevent the watch from firing, you could end up with one
trying to load between the suspend and resume.

If you got rid of the feature to load the requested accelerator
automatically when the configuration changes, then yes, that might be
possible, but I think I'd rather leave that in and use an extra lock and
some state to ignore the watch firing at bad times.  This would mean we
could leave the watch in place during the suspend/resume/cancel cycle
(refreshing on resume).  The suspend_cancel callback would still be
necessary, but it would just be acquiring a lock and modifying some
state rather than doing a xenbus watch operation.

It's not clear to me what the source of the long delay is, and whether
that change would solve it: the extra lock would be contended with the
watch handler's work queue, and so if the watch is the source of the
delay it's possible that we'd just contend in a different way and the
delay would still be there.  Brendan: can you explain the delay for me?


Xen-devel mailing list