On Sun, Jul 18, 2010 at 10:32:53PM +0200, Alexander Graf wrote:
>
> On 18.07.2010, at 22:09, Richard W.M. Jones wrote:
>
> > On Sun, Jul 18, 2010 at 07:26:57PM +0200, Alexander Graf wrote:
> >> On 17.07.2010, at 11:53, Richard W.M. Jones wrote:
> >>> On Sat, Jul 17, 2010 at 10:50:59AM +0100, Richard W.M. Jones wrote:
> >>>> I understand from the git logs that fw_cfg was added because the old
> >>>> way was to load kernel & initrd into RAM directly, but this didn't
> >>>> work because SeaBIOS would clear the RAM, clobbering kernel & initrd.
> >>>> Could we change to loading these directly into RAM, and instead
> >>>> provide some indication to SeaBIOS so it doesn't clobber the RAM? I'm
> >>>> quite prepared to do the work, just wondering if there's something
> >>>> else I'm not getting about this.
> >>>
> >>> Or thinking around the subject:
> >>>
> >>> Change fw_cfg so that you send a command + a physical address, and
> >>> fw_cfg memcpy's the kernel / initrd / etc to that physical address.
> >>> Then linuxboot.bin doesn't have to do the manual copying.
> >>>
> >>> Or just change linuxboot.bin so it does 32 bit inl instructions, which
> >>> might at least be a bit faster ...
> >>
> >> I don't see why it would be slow. ins should be emulated using coalesced
> >> mmio, no?
> >
> > It knocks 1 second off libguestfs boot times on my faster 64 bit
> > desktop machine, and 2 seconds off with my old 32 bit laptop.
> > (Roughly 15% faster in both cases)
> >
> > The 64 bit machine times are:
> >
> > Without my patch:
> >
> > real 0m7.581s
> > user 0m4.730s
> > sys 0m2.124s
> >
> > With my patch:
> >
> > real 0m6.579s
> > user 0m3.614s
> > sys 0m1.941s
> >
> > If you want to reproduce this (you'll need a recent Fedora machine)
> > you can do:
> >
> > $ cat qemu-wrapper
> > #!/bin/sh -
> > qemudir=/home/rjones/d/qemu
> > exec $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios "$@"
> >
> > $ export LIBGUESTFS_QEMU=/home/rjones/d/qemu/qemu-wrapper
> > $ time guestfish --ro -a /dev/null run
> >
> > Obviously I'm running that several times over, discarding the first
> > few runs, because I'm only interested in the "hot cache" case.
> >
> > By the way, even if you reject the patch as a whole, part 1/2 of the
> > patch is just an obvious bug fix, and I think should be applied
> > anyway.
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2010-07/threads.html#00967
>
> I haven't rejected anything yet - in general I like the idea of DMA'ing
> fw_cfg variables. I guess since it's basically an ISA PV device, we also
> don't need to care about bus mastering or anything, right? Or do we? Hrm.
>
That what I am warring about too. If we are adding device we have to be
sure such device can actually exist on real hw too otherwise we may have
problems later. Also 1 second on 100M file does not look like huge gain
to me.
--
Gleb.
