Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Fri, Jun 26, 2015 at 05:44:59PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [libvirt test] 58119: regressions - 
> FAIL"):
> > FYI, I have looked at how long it takes for QEMU to start, from libxl point
> > of view, and from strace point of view.
> > 
> > For libxl, I have look at the time difference between a call to
> > libxl__ev_xswatch_register('device-model/$domid/path') and
> > libxl__qmp_initialize():
> > cat deltatime | sort | uniq -c
> >   2754 0:00:00
> >   1309 0:00:01
> >     12 0:00:02
> >      8 0:00:03
> >      5 0:00:04
> >      1 0:00:05
> >      4 0:00:06
> >      7 0:00:07
> >      6 0:00:08
> >      1 0:00:09
> >      2 0:00:10
> >     16 timeout: 0:00:10
> 
> Is this information from merlot ?

No, this data is gathered on a local machine running OpenStack (the whole
stack).

> > >From straces, it is the time between the execve() call and when QEMU
> > respond to a QMP connection. The average is 0.316729, and the standard
> > deviation is 0.460369 (The average and std deviation does not take into
> > account the QEMUs that timed out).  But, out of the 3386 QEMU startup,
> > there are 26 run that took between 2s and 10s, and there are 14
> > more qemu run that have timed out.
> > 
> > I'm going to send a patch to ask to increase the timeout.
> 
> I think you have not explained why these long startup times are to be
> expected.  If they are _not_ expected, we should not be covering up
> for them by increasing the timeout.

I will try to answer to this in the patch description.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel