From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mj7wx-000457-Mz for qemu-devel@nongnu.org; Thu, 03 Sep 2009 04:45:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mj7wr-00044R-Og for qemu-devel@nongnu.org; Thu, 03 Sep 2009 04:45:47 -0400 Received: from [199.232.76.173] (port=35252 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mj7wr-00044K-50 for qemu-devel@nongnu.org; Thu, 03 Sep 2009 04:45:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52445) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mj7wq-0001yq-Ir for qemu-devel@nongnu.org; Thu, 03 Sep 2009 04:45:40 -0400 Message-ID: <4A9F8230.80101@redhat.com> Date: Thu, 03 Sep 2009 11:45:36 +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> In-Reply-To: <1251939158-17153-1-git-send-email-glommer@redhat.com> 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:52 AM, Glauber Costa wrote: > Hi guys > > In this patch, I am attaching an early version of a new "on_vcpu" mechanism (after > making it generic, I saw no reason to keep its name). It allows us to guarantee > that a piece of code will be executed in a certain vcpu, indicated by a CPUState. > > I am sorry for the big patch, I just dumped what I had so we can have early directions. > When it comes to submission state, I'll split it accordingly. > > As we discussed these days at qemu-devel, I am using pthread_set/get_specific for > dealing with thread-local variables. Note that they are not used from signal handlers. > A first optimization would be to use TLS variables where available. > > In vl.c, I am providing a version of queue_work for the IO-thread, and other for normal > operation. The "normal" one should fix the problems Jan is having, since it does nothing > more than just issuing the function we want to execute. > > The io-thread version is tested with both tcg and kvm, and works (to the extent they were > working before, which in kvm case, is not much) > 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). Why do we need queue_work() in the first place? Is there a way to limit the queue size to prevent overflow? -- error compiling committee.c: too many arguments to function