From: "Richard W.M. Jones" <rjones@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
"Gabriel L. Somlo" <gsomlo@gmail.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Jordan Justen <jordan.l.justen@intel.com>,
Xiang Zheng <xiang.zheng@linaro.org>
Subject: Re: [PATCH 0/5] ArmVirtPkg, OvmfPkg: improve firmware duration of direct kernel boot
Date: Fri, 16 Mar 2018 14:47:17 +0000 [thread overview]
Message-ID: <20180316144717.GD2787@redhat.com> (raw)
In-Reply-To: <14834447-0d0c-2f2d-5553-ccdfc256d3f4@redhat.com>
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
><rescue> 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
next prev parent reply other threads:[~2018-03-16 14:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 19:02 [PATCH 0/5] ArmVirtPkg, OvmfPkg: improve firmware duration of direct kernel boot Laszlo Ersek
2018-03-15 19:02 ` [PATCH 1/5] ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot devices" Laszlo Ersek
2018-03-16 9:58 ` Ard Biesheuvel
2018-03-16 13:40 ` Laszlo Ersek
2018-03-16 13:45 ` Ard Biesheuvel
2018-03-16 14:06 ` Laszlo Ersek
2018-03-15 19:02 ` [PATCH 2/5] OvmfPkg/PlatformBootManagerLib: wrap overlong lines in "BdsPlatform.c" Laszlo Ersek
2018-03-15 19:02 ` [PATCH 3/5] OvmfPkg/PlatformBootManagerLib: rejuvenate old-style function comments Laszlo Ersek
2018-03-15 19:02 ` [PATCH 4/5] OvmfPkg/PlatformBootManagerLib: hoist PciAcpiInitialization() Laszlo Ersek
2018-03-16 15:27 ` Gabriel L. Somlo
2018-03-15 19:02 ` [PATCH 5/5] OvmfPkg/PlatformBootManagerLib: process "-kernel" before boot devices Laszlo Ersek
2018-03-16 8:57 ` [PATCH 0/5] ArmVirtPkg, OvmfPkg: improve firmware duration of direct kernel boot Richard W.M. Jones
2018-03-16 9:59 ` Richard W.M. Jones
2018-03-16 14:02 ` Laszlo Ersek
2018-03-16 14:47 ` Richard W.M. Jones [this message]
2018-03-16 17:46 ` Laszlo Ersek
2018-03-16 14:08 ` Ard Biesheuvel
2018-03-16 15:29 ` Gabriel L. Somlo
2018-03-16 17:49 ` Laszlo Ersek
2018-03-16 19:02 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180316144717.GD2787@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox