From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [libvirt test] 58119: regressions - FAIL
Date: Fri, 26 Jun 2015 17:44:59 +0100
Message-ID: <21901.33163.547929.321814@mariner.uk.xensource.com>
References: <osstest-58119-mainreport@xen.org>
	<1433755348.7108.402.camel@citrix.com>
	<20150623111538.GH3393@perard.uk.xensource.com>
	<1435064238.28264.209.camel@citrix.com>
	<20150623133223.GI3393@perard.uk.xensource.com>
	<20150626115501.GL3393@perard.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20150626115501.GL3393@perard.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Jim Fehlig <jfehlig@suse.com>, xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

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 ?

> >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.

Ian.