From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JnheC-0005nR-Cd for qemu-devel@nongnu.org; Sun, 20 Apr 2008 18:04:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JnheB-0005nA-Ni for qemu-devel@nongnu.org; Sun, 20 Apr 2008 18:04:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnheB-0005n7-L8 for qemu-devel@nongnu.org; Sun, 20 Apr 2008 18:04:31 -0400 Received: from an-out-0708.google.com ([209.85.132.250]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JnheB-0007IZ-NP for qemu-devel@nongnu.org; Sun, 20 Apr 2008 18:04:31 -0400 Received: by an-out-0708.google.com with SMTP id d26so492970and.130 for ; Sun, 20 Apr 2008 15:04:28 -0700 (PDT) Message-ID: <480BBDE9.5040209@codemonkey.ws> Date: Sun, 20 Apr 2008 17:04:25 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Linux SIGIO handling changes References: <12086832292508-git-send-email-mail@flac.kalibalik.dk> In-Reply-To: <12086832292508-git-send-email-mail@flac.kalibalik.dk> 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 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. Regards, Anthony Liguori > Cheers, > Anders. > > > >