Do you see all interrupts going to the same CPU? If yes is irqbalance in guest running?
On Mon, Mar 18, 2013 at 10:50:19AM +0100, Alexandre DERUMIER wrote: > Hello, about this bug, > > > Last Proxmox distrib use 2.6.32 rhel 6.3 kernel + qemu 1.4 , and have this > problem with guest with 2.6.32 kernel. > > do you think that +x2apic in guest cpu could help ? > > (I think it's enable by default in RHEV/OVIRT ? but not in proxmox) > > > > ----- Mail original ----- > > De: "Michael S. Tsirkin" <m...@redhat.com> > À: "Peter Lieven" <p...@dlhnet.de> > Cc: "Davide Guerri" <d.gue...@unidata.it>, "Alexandre DERUMIER" > <aderum...@odiso.com>, "Stefan Hajnoczi" <stefa...@gmail.com>, > qemu-devel@nongnu.org, "Jan Kiszka" <jan.kis...@web.de>, "Peter Lieven" > <lieven-li...@dlhnet.de>, "Dietmar Maurer" <diet...@proxmox.com> > Envoyé: Dimanche 17 Mars 2013 10:08:17 > Objet: Re: [Qemu-devel] slow virtio network with vhost=on and multiple cores > > On Fri, Mar 15, 2013 at 08:23:44AM +0100, Peter Lieven wrote: > > On 15.03.2013 00:04, Davide Guerri wrote: > > >Yes this is definitely an option :) > > > > > >Just for curiosity, what is the effect of "in-kernel irqchip"? > > > > it emulates the irqchip in-kernel (in the KVM kernel module) which > > avoids userspace exits to qemu. in your particular case I remember > > that it made all IRQs deliverd to vcpu0 on. So I think this is a workaround > > and not the real fix. I think Michael is right that it is a > > client kernel bug. It would be good to find out what it is and ask > > the 2.6.32 maintainers to include it. i further have seen that > > with more recent kernels and inkernel-irqchip the irqs are delivered > > to vcpu0 only again (without multiqueue). > > > > >Is it possible to disable it on a "live" domain? > > > > try it. i don't know. you definetely have to do a live migration for it, > > but I have no clue if the VM will survice this. > > > > Peter > > I doubt you can migrate VMs between irqchip/non irqchip configurations. > > > > > > >Cheers, > > > Davide > > > > > > > > >On 14/mar/2013, at 19:21, Peter Lieven <p...@dlhnet.de> wrote: > > > > > >> > > >>Am 14.03.2013 um 19:15 schrieb Davide Guerri <d.gue...@unidata.it>: > > >> > > >>>Of course I can do some test but a kernel upgrade is not an option here > > >>>:( > > >> > > >>disabling the in-kernel irqchip (default since 1.2.0) should also help, > > >>maybe this is an option. > > >> > > >>Peter > > >> > > >> > > >