From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjCbA-00048i-RB for qemu-devel@nongnu.org; Thu, 03 Sep 2009 09:43:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjCb5-00044g-8W for qemu-devel@nongnu.org; Thu, 03 Sep 2009 09:43:35 -0400 Received: from [199.232.76.173] (port=47695 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjCb5-00044d-2E for qemu-devel@nongnu.org; Thu, 03 Sep 2009 09:43:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55954) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjCb4-0006Md-PU for qemu-devel@nongnu.org; Thu, 03 Sep 2009 09:43:31 -0400 Message-ID: <4A9FC7FF.8010602@redhat.com> Date: Thu, 03 Sep 2009 16:43:27 +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> <4A9FA95D.60404@redhat.com> <20090903121135.GQ30340@mothafucka.localdomain> In-Reply-To: <20090903121135.GQ30340@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 03:11 PM, Glauber Costa wrote: > On Thu, Sep 03, 2009 at 02:32:45PM +0300, Avi Kivity wrote: > >> 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. >> > Initially, I thought we could use it for batching, if we forced a flush in the end of > a sequence of operations. This can makes things faster if we are doing a bunch of calls > in a row, from the wrong thread. > It's a lot easier and safer to write a function that does your batch job and on_vcpu() it. >> 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). >> > I respectfully disagree. Not that I want people not to know what they are doing, but I > believe that, forcing something that can only run in a specific thread to be run there, > provides us with a much saner interface, that will make code a lot more readable and > maintainable. > Example: kvm_vcpu_ioctl(get_regs) regs->rflags |= some_flag kvm_vcpu_ioctl(set_regs) This looks totally sane but is racy if kvm_vcpu_ioctl() does an implicit on_vcpu(). >> 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. >> > I will assume you meant "the other is assynchronous". It does not need to be. > I though about including the assynchronous version in this RFC to let doors > open for performance improvements *if* we needed them. But again: the absolute > majority of the calls will be local. So it is not that important. > Then there's even less reason to include the async version. >> on_vcpu() is a subset of queue_work(). I meant, why to we need the >> extra functionality? >> > As I said, if you oppose it hardly, we don't really need to. > I do oppose it, but the reason for not including it should be the reasons I cited, not that I oppose it. >> A more powerful API comes with increased responsibilities. >> > You suddenly sounds like spider man. > I hate it when I get unmasked. -- error compiling committee.c: too many arguments to function