On Tue, Aug 03, 2010 at 02:33:02PM +0300, Gleb Natapov wrote: > On Tue, Aug 03, 2010 at 12:13:06PM +0100, Richard W.M. Jones wrote: > > > > qemu compiled from today's git. Using the following command line: > > > > $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios \ > > -drive file=/dev/null,if=virtio \ > > -enable-kvm \ > > -nodefaults \ > > -nographic \ > > -serial stdio \ > > -m 500 \ > > -no-reboot \ > > -no-hpet \ > > -net user,vlan=0,net=169.254.0.0/16 \ > > -net nic,model=ne2k_pci,vlan=0 \ > > -kernel /tmp/libguestfsEyAMut/kernel \ > > -initrd /tmp/libguestfsEyAMut/initrd \ > > -append 'panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_vmchannel=tcp:169.254.2.2:35007 guestfs_verbose=1 TERM=xterm-color ' > > > > With kernel 2.6.35 [*], this takes about 1 min 20 s before the guest > > starts. > > > > If I revert back to kernel 2.6.34, it's pretty quick as usual. > > > > strace is not very informative. It's in a loop doing select and > > reading/writing from some file descriptors, including the signalfd and > > two pipe fds. > > > > Anyone seen anything like this? > > > I assume your initrd is huge. It's ~110MB, yes. > In newer kernels ins/outs are much slower that they were. They are > much more correct too. It shouldn't be 1 min 20 sec for 100M initrd > though, but it can take 20-30 sec. This belongs to kvm list BTW. I can't see anything about this in the kernel changelog. Can you point me to the commit or the key phrase to look for? Also, what's the point of making in/out "more correct" when they we know we're talking to qemu (eg. from the CPUID) and we know it already worked fine before with qemu? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
