From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JnwE2-0004cL-Vx for qemu-devel@nongnu.org; Mon, 21 Apr 2008 09:38:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JnwDt-0004aq-Gy for qemu-devel@nongnu.org; Mon, 21 Apr 2008 09:38:30 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnwDt-0004an-6z for qemu-devel@nongnu.org; Mon, 21 Apr 2008 09:38:21 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JnwDr-0008LN-MS for qemu-devel@nongnu.org; Mon, 21 Apr 2008 09:38:20 -0400 Message-ID: <480C98B3.7050905@qumranet.com> Date: Mon, 21 Apr 2008 16:37:55 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Linux SIGIO handling changes References: <12086832292508-git-send-email-mail@flac.kalibalik.dk> <480BBDE9.5040209@codemonkey.ws> In-Reply-To: <480BBDE9.5040209@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > Anders Melchiorsen wrote: >> I am resending this patch, split into two parts now. >> >> This cleans up SIGIO handling to improve latency: >> - SIGALRM for alarm timers >> - enable SIGIO on qemu_set_fd_handler2() >> >> The issue was found in KVM, where it is much more visible, >> because there is no periodic timer. However, it has been >> confirmed (by Aurelien Jarno) that even for qemu, this >> approach "improves network transfers in a huge way". >> >> Please apply, or give a firm rejection so I can stop resending. >> > > Probably the right thing to do is the direction KVM is moving toward, > i.e. have a separate IO thread. > > Setting SIGIO on every file descriptor is really just a hack to break > out of the cpu exec loop. It's unclear to me whether it's really > always the right thing to do for every file descriptor. > Even with a separate iothread one needs the signals, as there is no other race-free way to poll for both aio completions and fd readiness. [well, pselect works, but I dislike it and it isn't present on all kernels] -- error compiling committee.c: too many arguments to function