qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack int


From: Avi Kivity
Subject: Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends
Date: Tue, 11 Oct 2011 11:26:14 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 10/11/2011 11:19 AM, Alexander Graf wrote:
>>
>>  Of this, 1.4 seconds is the time required by LinuxBoot to copy the
>>  kernel+initrd. If I used an uncompressed initrd, which I really want
>>  to, to avoid decompression overhead, this increases to ~1.7 seconds.
>>  So the LinuxBoot ROM is ~60% of total QEMU execution time, or 40%
>>  of total sandbox execution overhead.
>
>  One thing we can do is boot a guest and immediately snapshot it, before it 
runs any application specific code.  Subsequent invocations will MAP_PRIVATE the 
memory image and COW their way.  This avoids the kernel initialization time as 
well.

That doesn't allow modification of -append

Is it really needed?

and gets you in a pretty bizarre state when doing updates of your host files, 
since then you have 2 different paths: full boot and restore. That's yet 
another potential source for bugs.

Typically you'd check the timestamps to make sure you're running an up-to-date version.


>
>>
>>  For comparison I also did a test building a bootable ISO using ISOLinux.
>>  This required 700 ms for the boot time, which is appoximately 1/2 the
>>  time reqiured for direct kernel/initrd boot. But you have to then add
>>  on time required to build the ISO on every boot, to add custom kernel
>>  command line args. So while ISO is faster than LinuxBoot currently
>>  there is still non-negligable overhead here that I want to avoid.
>
>  You can accept parameters from virtio-serial or some other channel.  Is 
there any reason you need them specifically as *kernel* command line parameters?

That doesn't work for kernel parameters. It also means things would have to be 
rewritten needlessly. Some times we can't easily change the way parameters are 
passed into the guest either, for example when running a random (read: old, 
think of RHEL5) distro installation initrd.

This use case is not installation, it's for app sandboxing.

And I don't see the point why we would have to shoot yet another hole into the 
guest just because we're too unwilling to make an interface that's perfectly 
valid horribly slow.

rep/ins is exactly like dma+wait for this use case: provide an address, get a memory image in return. There's no need to add another interface, we should just optimize the existing one.

--
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]