From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjAYk-0001Mo-0M for qemu-devel@nongnu.org; Thu, 03 Sep 2009 07:32:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjAYb-0001M7-Jd for qemu-devel@nongnu.org; Thu, 03 Sep 2009 07:32:53 -0400 Received: from [199.232.76.173] (port=55946 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjAYb-0001M1-3H for qemu-devel@nongnu.org; Thu, 03 Sep 2009 07:32:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44422) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjAYa-0007wo-Az for qemu-devel@nongnu.org; Thu, 03 Sep 2009 07:32:48 -0400 Message-ID: <4A9FA95D.60404@redhat.com> Date: Thu, 03 Sep 2009 14:32:45 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] queue_work proposal References: <1251939158-17153-1-git-send-email-glommer@redhat.com> <4A9F8230.80101@redhat.com> <20090903111505.GO30340@mothafucka.localdomain> In-Reply-To: <20090903111505.GO30340@mothafucka.localdomain> 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: Glauber Costa Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On 09/03/2009 02:15 PM, Glauber Costa wrote: > >> on_vcpu() and queue_work() are fundamentally different (yes, I see the >> wait parameter, and I think there should be two separate functions for >> such different behaviours). >> > Therefore, the name change. The exact on_vcpu behaviour, however, can be > implemented ontop of queue_work(). Will there be any use for asynchronous queue_work()? It's a dangerous API. > Instead of doing that, I opted for using it > implicitly inside kvm_vcpu_ioctl, to guarantee that vcpu ioctls will always run > on the right thread context. I think it's reasonable to demand that whoever calls kvm_vcpu_ioctl() know what they are doing (and they'll get surprising results if it switches threads implicitly). > Looking at qemu-kvm, it seems that there are a couple > of other functions that are not ioctls, and need on_vcpu semantics. Using them becomes > a simple matter of doing: > > queue_work(env, func, data, 1); > > I really don't see the big difference you point. They are both there to force a specific > function to be executed in the right thread context. > One of them is synchronous, meaning the data can live on stack and no special synchronization is needed, while the other is synchronous, meaning explicit memory management and end-of-work synchronization is needed. >> Why do we need queue_work() in the first place? >> > To force a function to be executed in the correct thread context. > Why do we need on_vcpu in the first place? > on_vcpu() is a subset of queue_work(). I meant, why to we need the extra functionality? >> Is there a way to limit the queue size to prevent overflow? >> > It can be, but it gets awkward. What do you do when you want a function needs to execute > on another thread, but you can't? Block it? Refuse? > What if the thread is busy? You grow the queue to an unbounded size? > We could pick one, but I see no need. The vast majority of work will never get queued, > since we'll be in the right context already. > A more powerful API comes with increased responsibilities. -- error compiling committee.c: too many arguments to function