[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Skip vcpu_hotplug for VCPU 0 in smp_resume
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? Kieran _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |