From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=rjones@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B52D5220C2A7F for ; Fri, 16 Mar 2018 07:40:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCACFC00F6E7; Fri, 16 Mar 2018 14:47:19 +0000 (UTC) Received: from localhost (unknown [10.36.118.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 672957A24E; Fri, 16 Mar 2018 14:47:17 +0000 (UTC) Date: Fri, 16 Mar 2018 14:47:17 +0000 From: "Richard W.M. Jones" To: Laszlo Ersek Cc: edk2-devel-01 , "Gabriel L. Somlo" , Ard Biesheuvel , Jordan Justen , Xiang Zheng Message-ID: <20180316144717.GD2787@redhat.com> References: <20180315190258.6580-1-lersek@redhat.com> <20180316095950.GZ2787@redhat.com> <14834447-0d0c-2f2d-5553-ccdfc256d3f4@redhat.com> MIME-Version: 1.0 In-Reply-To: <14834447-0d0c-2f2d-5553-ccdfc256d3f4@redhat.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 16 Mar 2018 14:47:19 +0000 (UTC) Subject: Re: [PATCH 0/5] ArmVirtPkg, OvmfPkg: improve firmware duration of direct kernel boot X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 14:40:56 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 16, 2018 at 03:02:57PM +0100, Laszlo Ersek wrote: > On 03/16/18 10:59, Richard W.M. Jones wrote: > > On Thu, Mar 15, 2018 at 08:02:53PM +0100, Laszlo Ersek wrote: > >> Please attach a good number of disks at once on the command line, > > > > I read this bit then forgot to do it :-/ > > > > The test suite has a test for adding a large number of drives: > > > > https://github.com/libguestfs/libguestfs/tree/master/tests/disks > > > > so it's quite easy for me to test this: > > > > $ time ./test-add-disks -n 100 > > What kind of disks does this test add, virtio-blk or virtio-scsi? > > And I assume PCI, not virtio-mmio? virtio-scsi & PCI. I think we are still using virtio-mmio in RHEL 7? But anyway the tests were performed with the latest upstream stuff. > It's possible that with a hundred disks, you hit a limit in the firmware > before all the time was spent that would have been necessary to bind all > hundred disks. I mean, the point is exactly to prevent the firmware from > spending time on those disks, but it should be due to a controlled > restriction, not resource exhaustion, and the comparison should use a > test case where the firmware does manage to bind them all (without the > patches). There's actually a load of problems on x86, mainly with the BIOS & kernel and how long it takes to enumerate the disks. I didn't look closely at what it's trying to do on aarch64. > ... We could go into the various limits here, regarding PCI bus number > space, virtio-scsi targets and LUNs, but I think it would be premature > before seeing a domain XML or a QEMU command line. (Also, my apologies > for being vague with "good number of ...".) An easy way to reproduce this is: # dnf install /usr/bin/virt-rescue $ virt-rescue --scratch=100 > ls /dev/sd Display all 101 possibilities? (y or n) sda sdah sdap sdax sdbe sdbm sdbu sdcb sdcj sdcr sdf sdn sdv sdaa sdai sdaq sday sdbf sdbn sdbv sdcc sdck sdcs sdg sdo sdw sdab sdaj sdar sdaz sdbg sdbo sdbw sdcd sdcl sdct sdh sdp sdx sdac sdak sdas sdb sdbh sdbp sdbx sdce sdcm sdcu sdi sdq sdy sdad sdal sdat sdba sdbi sdbq sdby sdcf sdcn sdcv sdj sdr sdz sdae sdam sdau sdbb sdbj sdbr sdbz sdcg sdco sdcw sdk sds sdaf sdan sdav sdbc sdbk sdbs sdc sdch sdcp sdd sdl sdt sdag sdao sdaw sdbd sdbl sdbt sdca sdci sdcq sde sdm sdu > indeed this patch should only improve boot time. In your other email, > you mention "libguestfs-boot-benchmark". Does that include kernel boot > time as well? libguestfs-boot-benchmark just starts the appliance (and kernel and userspace) and shuts it down, so it's as close to testing raw boot performance as you can get. However it only uses I think 1 or 2 disks, so it's not testing lots of devices. > ... OTOH, it probably should too. An interactive user definitely cares > about the time between (a) hitting Enter on the "guestfish" command and > (b) getting the guestfish prompt. Where the boot transitions from > firmware to kernel is irrelevant to the user. > > Sorry to bother you with another request, but I currently have no access > to my aarch64 hardware (so that I could test on aarch64 KVM); could you > please compare boot benchmark results using, say, eight disks? Something > like: > > time guestfish --ro \ > -a disk1.img \ > ... \ > -a disk8.img \ > launch : quit > > (I hope this test case is not totally bogus.) An easier way is this as follows. I missed out the --just-add option in my previous tests, which causes the test to do a lot more testing. With the option it just adds them, launches the appliance and shuts down. $ time ./test-add-disks --just-add -n 8 Results: with Fedora AAVMF: 0m11.197s 0m10.075s 0m10.033s with your firmware: 0m5.395s 0m5.385s 0m5.354s Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org