From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60538 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PpUPU-0002qV-T3
	for qemu-devel@nongnu.org; Tue, 15 Feb 2011 18:34:21 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1PpUPU-00043A-0Y
	for qemu-devel@nongnu.org; Tue, 15 Feb 2011 18:34:20 -0500
Received: from mx1.redhat.com ([209.132.183.28]:15200)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1PpUPT-000432-Or
	for qemu-devel@nongnu.org; Tue, 15 Feb 2011 18:34:19 -0500
Date: Tue, 15 Feb 2011 20:03:30 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20110215220330.GA2547@amt.cnet>
References: <4D58FAF2.6070106@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D58FAF2.6070106@siemens.com>
Subject: [Qemu-devel] Re: [RFC] Some more io-thread optimizations
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: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, Aurelien Jarno <aurelien@aurel32.net>

On Mon, Feb 14, 2011 at 10:50:42AM +0100, Jan Kiszka wrote:
> Hi,
> 
> patch below further reduces the io-thread overhead in tcg mode so that
> specifically emulating smp boxes gets noticeably faster. Its essence:
> poll the file descriptors until select returns 0, keeping the global
> mutex locked. This reduces ping pong with the vcpu threads, most
> noticeably in tcg mode where we run in lock-step.
> 
> Split up in two patches, I'm planning to route those changes via the kvm
> queue (as they collide with other patches there).
> 
> Jan

Not sure this makes sense for all cases. There could be scenarios where
a single pass is more efficient (think latency to acquire mutex from
vcpu context in kvm mode, with intensive file IO in progress).