From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:58229)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pl@dlhnet.de>) id 1UGOzN-0008RM-T4
	for qemu-devel@nongnu.org; Fri, 15 Mar 2013 03:23:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@dlhnet.de>) id 1UGOzL-00057y-GM
	for qemu-devel@nongnu.org; Fri, 15 Mar 2013 03:23:41 -0400
Received: from ssl.dlhnet.de ([91.198.192.8]:40130 helo=ssl.dlh.net)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@dlhnet.de>)
	id 1UGOzL-00057j-A9
	for qemu-devel@nongnu.org; Fri, 15 Mar 2013 03:23:39 -0400
Message-ID: <5142CC80.503@dlhnet.de>
Date: Fri, 15 Mar 2013 08:23:44 +0100
From: Peter Lieven <pl@dlhnet.de>
MIME-Version: 1.0
References: <EE07F1D6-13DE-455C-8679-C4E29CA848CA@unidata.it>
	<6ce47933-c4df-4a64-9b94-69922ea3ef9a@mailpro>
	<20130314175003.GD29411@redhat.com>
	<72939A33-1A1D-4D5B-88CB-22D2F6803428@unidata.it>
	<14BEFB3E-0F36-44C3-943A-F4EAE92AACA6@dlhnet.de>
	<36D0FF56-686D-47DC-80FD-8DA6A5F48309@unidata.it>
In-Reply-To: <36D0FF56-686D-47DC-80FD-8DA6A5F48309@unidata.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] slow virtio network with vhost=on and multiple
	cores
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Davide Guerri <d.guerri@unidata.it>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org, Alexandre DERUMIER <aderumier@odiso.com>, Jan Kiszka <jan.kiszka@web.de>, Peter Lieven <lieven-lists@dlhnet.de>, Dietmar Maurer <dietmar@proxmox.com>

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

>
> Cheers,
>   Davide
>
>
> On 14/mar/2013, at 19:21, Peter Lieven <pl@dlhnet.de> wrote:
>
>>
>> Am 14.03.2013 um 19:15 schrieb Davide Guerri <d.guerri@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
>>
>>
>