On Fri, Apr 01, 2016 at 04:05:46PM -0400, Kevin O'Connor wrote: > On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote: > > On Fri, Apr 01, 2016 at 11:35:40AM -0400, Kevin O'Connor wrote: > > > > +# general stuff > > > > +CONFIG_QEMU=y > > > > +CONFIG_ROM_SIZE=128 > > > > > > Why force a size of 128K - I would think 64K would be fine. > > > > Agreed. Setting this to =0 seems the best thing, and it does fit fine > > inside 64K. > > > > > > +# no input, no boot menu > > > > +CONFIG_MOUSE=n > > > > +CONFIG_KEYBOARD=n > > > [...] > > > > +CONFIG_DRIVES=n > > > > > > I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD, > > > CONFIG_DRIVES - I only had those in my config so as to avoid having to > > > specify all the device drivers. Ideally these would remain on and the > > > individual device drivers would be disabled. > > > > We are always use this in a virtual appliance. Interaction with the > > user is both impossible and undesirable. It either boots or not, and > > the whole appliance is discarded in seconds. We're always using > > -kernel with this SeaBIOS build, so probing drives is never needed. > > Okay, but if it doesn't change the boot time, then it would be nicer > to use a standard rom for all boots.
I don't think I know which option (or options) make the boot faster, but bios-fast.bin is certainly much faster than the qemu standard bios.bin -- no amount of variability in the test framework would account for that huge difference of 44ms. I had convinced myself before that maybe CONFIG_DRIVES=n was the factor, but that setting alone doesn't actually make much difference: bios-fast.bin (CONFIG_DRIVES=n): Result: 1093.3ms ±3.4ms Result: 1100.6ms ±8.9ms bios-fast.bin + CONFIG_DRIVES=y: Result: 1100.3ms ±8.4ms Result: 1101.7ms ±1.2ms It could be just one setting or an accumulation of several settings. At some point I may have the patience to try each one but probably not late on Friday night :-/ > I looked closer at your setup and it appears the SeaBIOS virtio-scsi > driver is very slow because it does a full search of all 256 possible > scsi targets. This full scan takes a lot of time. I put together a > quick patch (see below) to stop the scan early. Gerd/Paulo, do you > know if what I've done is valid and/or if there is a better way we can > limit the virtio-scsi scan? > > I also found a way to reduce the overhead of the "shadow ram" code a > little. I have a patch (see below) for that as well. I would say the patches on the KevinOConnor/testing branch don't make any measurable difference. Stock qemu SeaBIOS: Result: 1218.6ms ±1.0ms Result: 1214.1ms ±0.0ms KevinOConnor/testing branch: Result: 1221.9ms ±0.5ms Result: 1216.4ms ±0.2ms > Another consumer of time is ACPI table deployment. I wonder if you > could get similar results by running QEMU with "-no-acpi"? No apparent difference: Stock qemu SeaBIOS: Result: 1211.5ms ±4.8ms Stock qemu SeaBIOS + qemu -no-acpi: Result: 1213.9ms ±6.5ms > Beyond that, I think the only other big time consumers of the default > seabios is debug messages. If so, then I think we can come up with a > way to limit these debug messages in SeaBIOS. > > The SeaBIOS testing patches are at: > > https://github.com/KevinOConnor/seabios/tree/testing Thanks, 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
