Xen project Mailing List

On Thu, Dec 12, 2013 at 7:08 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

Shriram Rajagopalan writes ("Re: [Xen-devel] [PATCH 1 of 2] libxl: async version of domain suspend"):

> On Sunday, November 24, 2013, Shriram Rajagopalan wrote:

...

> libxl: async version of domain suspend

I don't seem to have replied to this. Sorry about that and thanks for
the ping.

Unfortunately, it's really not the right approach at all. The right
approach would be a series of incremental patches each of which makes
a smallish change and which can be reviewed. This is far from easy.

I have started work on this myself in the meantime and I have (so
far!) a 17-patch series which is far too disruptive to be suitable for
4.4. Indeed at this stage of the release these structural changes to
the suspend/resume code aren't really appropriate.

It would be nice to be able to get improved support for Remus in 4.4
if we can do so without adding too much risk. In particular I think
it would be fine to add code to support Remus network buffering if we
can get the interfaces right and non-Remus code isn't touched too
much.

True. If that is the case, the only change to the domain suspend code that I request

is to tweak those silly wait loops, one which enforces a mandatory 100ms wait before

checking whether the guest acked the suspend request and another 100ms wait before

even checking if the guest suspended. Matter of fact, if these hardcoded timer values

can be reduced to something like a "10ms wait for first attempt, 40-50ms wait for

subsequent attempts" then it might be beneficial to both remus and live migration.

NB: This is simply a bug fix and not a change in the way the control flows.

The code would still remain synchronous for the moment.

I'm not sure what George (the release manager) will think of
libxl: make libxl__domain_suspend_callback be asynchronous
which I think is a precondition for code which runs the Remus
network buffering script. I'm about to bounce a copy to him.

I have kept the Remus series independent of this. Infact, the changes

I suggested above are more than sufficient.

And FYI, the network buffering script is a one time invocation when Remus starts.

It is not called in the context of domain suspend callbacks. The only network buffering

related code in the suspend callback is invocation of libnl3 APIs

Ian.