public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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