From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=48869 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P36B1-0001yh-7w
	for qemu-devel@nongnu.org; Tue, 05 Oct 2010 07:59:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1P36AY-0005nL-BO
	for qemu-devel@nongnu.org; Tue, 05 Oct 2010 07:59:21 -0400
Received: from mx1.redhat.com ([209.132.183.28]:5304)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1P36AY-0005my-4u
	for qemu-devel@nongnu.org; Tue, 05 Oct 2010 07:58:54 -0400
Message-ID: <4CAB12F4.30701@redhat.com>
Date: Tue, 05 Oct 2010 13:58:44 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1285855312-11739-1-git-send-email-stefanha@linux.vnet.ibm.com>	<4CA862A7.2080302@redhat.com>
	<AANLkTimg=mg0OR=uQ1prO9kxof+bRCZnB1jDaMNm78rr@mail.gmail.com>
In-Reply-To: <AANLkTimg=mg0OR=uQ1prO9kxof+bRCZnB1jDaMNm78rr@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] virtio: Use ioeventfd for virtqueue notify
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: rukhsana ansari <ruk.ansari@gmail.com>
Cc: Steve Dobbelstein <steved@us.ibm.com>, Anthony Liguori <aliguori@us.ibm.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Khoa Huynh <khoa@us.ibm.com>, Sridhar Samudrala <sri@us.ibm.com>

  On 10/05/2010 01:00 PM, rukhsana ansari wrote:
> Hi,
>
> W.r.t:
> >  Note that this is a tradeoff.  If an idle core is available and the
> >  scheduler places the iothread on that core, then the heavyweight exit is
> >  replaced by a lightweight exit + IPI.  If the iothread is co-located with
> >  the vcpu, then we'll take a heavyweight exit in any case.
> >
> Q: Does the kvm kernel code check for such a condition and take a
> heavyweight exit?

No.  The heavyweight exit is caused by a context switch (partial) or 
return to userspace (full).

> >  The first case is very likely if the host cpu is undercommitted and there is
> >  heavy I/O activity.  This is a typical subsystem benchmark scenario (as
> >  opposed to a system benchmark like specvirt).  My feeling is that total
> >  system throughput will be decreased unless the scheduler is clever enough to
> >  place the iothread and vcpu on the same host cpu when the system is
> >  overcommitted.
> >
> >
> Q: Sorry if the answer is obvious here.
> If the heavyweight exit is taken when both threads are assigned to the
> same core, how will the system throughput increase?
>

Co-locating threads on the same core reduces cross-core traffic.

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