[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |