I used the attached file (suspend_resume.c) in order to generate a log
interpreted by a "homemade" program wrote by me to create a graph analysis of
the suspend/resume of a guest during 30 minutes with suspend/resume cycles of
100ms.
If you observe the ChartAnalysis.png you can see during the 30 minutes of the
suspend/resume test of the guest is very consistent, but it happen about 6
spikes (3 of them reaching about 400ms, about 600 to 700 times more than the
normal average). This test as perform with no CPU load on the dom0 and domU. I
leave you here some stats:
Minimum=0.468 ms
Arithmetic Mean=0.652 ms
Geometric Mean=0.552 ms
Maximum=401.251 ms
> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: quinta-feira, 28 de Julho de 2011 20:07
> To: Gustavo Pimentel
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; rshriram@xxxxxxxxx
> Subject: Re: Issues about domU suspending/resuming
>
> Perhaps run a program in domU which calls gettimedofday() in a loop and logs
> big deltas between successive calls. If the domain is otherwise idle, you
> can probbaly set the threshold to only trigger during the suspend phase of
> live migration. Then you don't need to hook into the suspend/resume parts of
> the toolstack.
>
> -- Keir
>
>
> On 28/07/2011 19:22, "Gustavo Pimentel" <gustavo.pimentel@xxxxxxxxxx> wrote:
>
> > I didn't test the suspend/resuming with basic live migration.
> > Do you know how can I invoke some xen api in order to suspend/resuming the
> > guest? I could make a simple program to be able to log times of
> > suspending/resuming and on the future to analysis the basic live migration.
> > Meanwhile I leave here some information about the my test system:
> > I using xen4.2-unstable on a Intel(R) Pentium(R) 4 CPU 3.20GHz processor
> > with
> > hyperthread, using credit scheduler. I have pinning dom0 to vcpu0 and domU
> > to
> > vcpu1.
> > I have on dom0 the kernel version 2.6.32.40 and on domU the kernel version
> > 2.6.18 kernel which has fast suspend support.
> >
> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> >> Sent: quinta-feira, 28 de Julho de 2011 18:33
> >> To: Gustavo Pimentel
> >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: Issues about domU suspending/resuming
> >>
> >> On 28/07/2011 18:16, "Gustavo Pimentel" <gustavo.pimentel@xxxxxxxxxx>
> wrote:
> >>
> >>> It's not really a bug, but a performance analysis.
> >>> I'm using remus for a HA system and after a system analysis using remus
> >>> log,
> >>> I
> >>> notice that suspending a the guest can oscillate between 0.299ms to
> >>> 812.909ms.
> >>> And the resuming of the same guest oscillates between 0.387ms to
> 1745,579ms.
> >>> The guest it's a virtual machine with 64MB of RAM, without CPU load.
> >>>
> >>> It's very strange this large range of values of the suspend/resuming of a
> >>> guest.
> >>
> >> First point of contact would be the listed Remus maintainer. More data
> >> would
> >> be useful I expect -- e.g., does the variation occur with basic live
> >> migration (no Remus)?
> >>
> >> -- Keir
> >>
> >>>> -----Original Message-----
> >>>> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> >>>> Sent: quinta-feira, 28 de Julho de 2011 18:00
> >>>> To: Gustavo Pimentel
> >>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> >>>> Subject: Re: Issues about domU suspending/resuming
> >>>>
> >>>> On 28/07/2011 17:13, "Gustavo Pimentel" <gustavo.pimentel@xxxxxxxxxx>
> >> wrote:
> >>>>
> >>>>> Hi, I have looked into the MAINTAINERS file on the xen source, but I
> >>>>> didn¹t
> >>>>> find the specific maintainer for responsible for issues about domU
> >>>>> suspending/resuming procedure.
> >>>>> Can you point me to the right person?
> >>>>
> >>>> It crosses multiple subsystems. It could be a guest kernel bug for
> >>>> example,
> >>>> or a toolstack bug. Post a bug report to xen-devel and we can try to
> >>>> triage
> >>>> it.
> >>>>
> >>>> -- Keir
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
suspend_resume.c
Description: suspend_resume.c
ChartAnalysis.png
Description: ChartAnalysis.png
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|