qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: chegu_vinod@hp.com
Cc: Alex Williamson <alex.williamson@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Large sized guest taking for ever to boot...
Date: Fri, 08 Jun 2012 20:08:32 +0200	[thread overview]
Message-ID: <4FD23FA0.6060202@siemens.com> (raw)
In-Reply-To: <4FD23CF9.5000203@hp.com>

[CC'ing qemu as this discusses its code base]

On 2012-06-08 19:57, Chegu Vinod wrote:
> On 6/8/2012 10:42 AM, Alex Williamson wrote:
>> On Fri, 2012-06-08 at 10:10 -0700, Chegu Vinod wrote:
>>> On 6/8/2012 9:46 AM, Alex Williamson wrote:
>>>> On Fri, 2012-06-08 at 16:29 +0000, Chegu Vinod wrote:
>>>>> Hello,
>>>>>
>>>>> I picked up a recent version of the qemu (1.0.92 with some fixes)
>>>>> and tried it
>>>>> on x86_64 server (with host and the guest running 3.4.1 kernel).
>>> BTW, I observe the same thing if i were to use 1.1.50 version of the
>>> qemu... not sure if this is really
>>> related to qemu...
>>>
>>>>> While trying to boot a large guest (80 vcpus + 512GB) I observed
>>>>> that the guest
>>>>> took for ever to boot up...  ~1 hr or even more. [This wasn't the
>>>>> case when I
>>>>> was using RHEL 6.x related bits]
>>>> Was either case using device assignment?  Device assignment will map
>>>> and
>>>> pin each page of guest memory before startup, which can be a noticeable
>>>> pause on smallish (<16GB) guests.  That should be linear scaling though
>>>> and if you're using qemu and not qemu-kvm, not related.  Thanks,
>>> I don't have any device assignment at this point . Yes I am using qemu
>>> (not qemu-kvm)...
>> Just to be safe, are you using --enable-kvm with qemu?
> 
> Yes...

Unless you are using current qemu.git master (where it is enabled by
default), --enable-kvm does not activate the in-kernel irqchip support
for you. Not sure if that can make such a huge difference, but it is a
variation from qemu-kvm. You can enable it in qemu-1.1 with -machine
kernel_irqchip=on.

> 
> -----
> 
> /etc/qemu-ifup tap0
> 
> /usr/local/bin/qemu-system-x86_64 -enable-kvm \
> 
> -cpu
> Westmere,+rdtscp,+pdpe1gb,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+s
> 
> s,+acpi,+ds,+vme \
> -m 524288 -smp 80,sockets=80,cores=1,threads=1 \
> -name vm1 \
> -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/vm1.monitor,server,nowait
> \
> -drive
> file=/dev/libvirt_lvm/vm.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native
> \
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> \
> -monitor stdio \
> -net nic,macaddr=52:54:00:71:01:01 \
> -net tap,ifname=tap0,script=no,downscript=no \
> -vnc :4
> 
> /etc/qemu-ifdown tap0
> 
> ----
> 
>>> The issue seems very basic... 'was earlier running RHEL6.3 RC1 on the
>>> host and the guest and the host and the guest seemed to boot fine..
>> Note that RHEL is based on qemu-kvm.  Thanks,
> 
> Yep..knew that :)
> 
> I was using upstream qemu-kvm and was encouraged to move away from
> it...to qemu.

And that is good. :)

Is the problem present in current qemu-kvm.git? If yes, can you bisect
when it was introduced?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

       reply	other threads:[~2012-06-08 18:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <loom.20120608T181832-528@post.gmane.org>
     [not found] ` <1339173966.26976.95.camel@ul30vt>
     [not found]   ` <4FD23221.5090208@hp.com>
     [not found]     ` <1339177340.26976.111.camel@ul30vt>
     [not found]       ` <4FD23CF9.5000203@hp.com>
2012-06-08 18:08         ` Jan Kiszka [this message]
2012-06-08 18:20           ` [Qemu-devel] Large sized guest taking for ever to boot Chegu Vinod
2012-06-08 18:37             ` Jan Kiszka
2012-06-12 15:33               ` Chegu Vinod
2012-06-12 15:39                 ` Gleb Natapov
2012-06-12 18:44                   ` Chegu Vinod
2012-06-13  7:12                     ` Gleb Natapov
2012-06-13  8:14                       ` Avi Kivity
2012-06-10  9:30             ` Gleb Natapov
2012-06-10 13:29               ` Chegu Vinod

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-all 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=4FD23FA0.6060202@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=alex.williamson@redhat.com \
    --cc=chegu_vinod@hp.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).