From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Jt9qx-0002SY-9G
	for qemu-devel@nongnu.org; Mon, 05 May 2008 19:12:15 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Jt9qu-0002QB-Sj
	for qemu-devel@nongnu.org; Mon, 05 May 2008 19:12:14 -0400
Received: from [199.232.76.173] (port=41949 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Jt9qu-0002Pv-Mk
	for qemu-devel@nongnu.org; Mon, 05 May 2008 19:12:12 -0400
Received: from [77.75.163.100] (helo=smtp.hotelhot.dk)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mail@flac.kalibalik.dk>) id 1Jt9qu-0002WZ-K6
	for qemu-devel@nongnu.org; Mon, 05 May 2008 19:12:12 -0400
Message-ID: <481F9449.6040602@flac.kalibalik.dk>
Date: Tue, 06 May 2008 01:12:09 +0200
From: Anders <mail@flac.kalibalik.dk>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [4341] qemu: generate signals on tap I/O
References: <E1Jt8Cq-0007Qs-U7@cvs.savannah.gnu.org>	<481F84F3.6060505@flac.kalibalik.dk>	<481F86F3.4080007@aurel32.net>
	<481F8D57.40500@flac.kalibalik.dk> <481F8DE5.9040905@codemonkey.ws>
In-Reply-To: <481F8DE5.9040905@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org

Anthony Liguori wrote:
> You're seeing improvement with normal QEMU?  Can you please post a 
> description of what you're seeing improve with SIGIO.  SIGIO should 
> really only slow things down.
>   

I found this issue in KVM. I have not timed in QEMU, but the issue 
seemed generic, so I posted it upstream.

My usecase was a new VNC connection delaying until the next timer tick 
(which is a really long time in some KVM configurations).

The improvement is from running the select() immediately, rather than 
waiting around for a timer to expire.

Thanks,
Anders.