From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NjaGb-0001pS-Oj for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:32:14 -0500 Received: from [199.232.76.173] (port=35939 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NjaGb-0001oq-0k for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:32:13 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NjaGa-0004zv-7o for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:32:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52894) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NjaGZ-0004zD-0X for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:32:12 -0500 Message-ID: <4B82A375.5000907@redhat.com> Date: Mon, 22 Feb 2010 17:32:05 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20100222135906.347393434@amt.cnet> <20100222140209.878250600@amt.cnet> <4B8292C4.9070802@redhat.com> <20100222142920.GB18992@amt.cnet> <4B829A02.3040605@redhat.com> <20100222151602.GD18992@amt.cnet> <4B82A2CB.3090003@codemonkey.ws> In-Reply-To: <4B82A2CB.3090003@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org On 02/22/2010 05:29 PM, Anthony Liguori wrote: > On 02/22/2010 09:16 AM, Marcelo Tosatti wrote: >>>> Are you concerned about spurious wakeups? >>> Yes. Also, qemu_notify_event() is an undirected notification (wakes >>> up all iothreads, and all devices), whereas ->handle_output() is >>> directed (wakes up exactly what is needed). >>> >>> What's the underlying problem? A new input buffer has become >>> available, and we need to re-poll the incoming file descriptor? If >>> so, that's best done from ->handle_output() (either by waking the >>> iothread or calling read() itself and perhaps receiving -EAGAIN). >> Yes. Sure, perhaps calling read() itself is appropriate, and i see >> your point that>handle_output contains more context for a smarter >> decision. >> >> But one can argue thats an improvement on top of a dumb wakeup. > > Spurious calls to qemu_notify_event() also make it difficult to tell > when it's actually necessary to call qemu_notify_event() vs. when it's > just something that doesn't hurt. One improvement in this area would be to add a context parameter (which eventually resolves to the underlying thread). Currently we'd ignore it since we have just one iothread, but it would serve to document what's being polled, and later direct the wakeup to the correct thread. -- error compiling committee.c: too many arguments to function