From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NjaQt-00052Z-Qs for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:42:51 -0500 Received: from [199.232.76.173] (port=34054 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NjaQt-00052G-AT for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:42:51 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NjaQr-0006N7-L7 for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:42:51 -0500 Received: from mail-ew0-f209.google.com ([209.85.219.209]:63445) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NjaQr-0006MT-84 for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:42:49 -0500 Received: by ewy1 with SMTP id 1so2668203ewy.16 for ; Mon, 22 Feb 2010 07:42:42 -0800 (PST) Message-ID: <4B82A5E7.2020706@codemonkey.ws> Date: Mon, 22 Feb 2010 09:42:31 -0600 From: Anthony Liguori 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> <4B82A375.5000907@redhat.com> In-Reply-To: <4B82A375.5000907@redhat.com> 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: Avi Kivity Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org On 02/22/2010 09:32 AM, Avi Kivity wrote: > 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. Ends up looking a lot like a condition. It's not necessarily a bad thing to model. Regards, Anthony Liguori