From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Njae8-0006AM-40 for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:56:32 -0500 Received: from [199.232.76.173] (port=60280 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Njae6-0006AD-PF for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:56:30 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Njae5-0007m5-Vd for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:56:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13151) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Njady-0007kT-8H for qemu-devel@nongnu.org; Mon, 22 Feb 2010 10:56:29 -0500 Message-ID: <4B82A902.8090405@redhat.com> Date: Mon, 22 Feb 2010 17:55:46 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY 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> <4B82A5E7.2020706@codemonkey.ws> In-Reply-To: <4B82A5E7.2020706@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:42 PM, Anthony Liguori wrote: >>> 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. > But the implementation is very different - condition variables sleep in pthread_cond_wait, the iothread sleeps in poll(). qemu_notify_event() is really requesting iothread t to re-add file fd to its poll set. Maybe we should make this a CharDriverState method. -- error compiling committee.c: too many arguments to function