From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSF4x-0006i2-N8 for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSF4s-0006dB-7W for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:30 -0500 Received: from [199.232.76.173] (port=34020 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSF4r-0006d3-Rh for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:25 -0500 Received: from mx20.gnu.org ([199.232.41.8]:35457) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSF4r-0002qi-AH for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:25 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NS98G-0004aL-Kd for qemu-devel@nongnu.org; Tue, 05 Jan 2010 08:07:32 -0500 Received: by yxe26 with SMTP id 26so15560967yxe.4 for ; Tue, 05 Jan 2010 05:06:31 -0800 (PST) Message-ID: <4B43394C.1040106@codemonkey.ws> Date: Tue, 05 Jan 2010 07:06:20 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1261382970-23251-1-git-send-email-pbonzini@redhat.com> <1261382970-23251-12-git-send-email-pbonzini@redhat.com> <4B424E95.4040806@codemonkey.ws> <4B42491C.1050709@redhat.com> <4B4280FC.4020602@codemonkey.ws> <4B43350A.7000309@redhat.com> In-Reply-To: <4B43350A.7000309@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 11/19] use a bottom half to run timers List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 01/05/2010 06:48 AM, Paolo Bonzini wrote: > On 01/05/2010 12:59 AM, Anthony Liguori wrote: >> >> When I think of a main loop, I think of something that provides the >> following three services >> >> 1) fd based events >> 2) time based events >> 3) an idle callback >> >> The problem we have is that bottom halves aren't quite idle callbacks. >> They have some really weird properties about the guarantees of when >> they're executed. At any rate, you really cannot express a time based >> event as an idle callback because you need to setup the select() timeout >> based on the next deadline and then dispatch timer event based on >> selects return. idle functions have none of this ability. > > I see bottom halves as a fourth service, providing the ability to > synchronize stuff that needs to execute in a particular thread > (guaranteeing thread-safety and especially signal-safety). Thread and signal safety are slightly different. Scheduling an idle callback from a signal handler is a pretty reasonable thing to do. Executing no a different thread is a whole different matter. Right now, we really use bottom halves to run something on the io thread and have a different mechanism that ran on a specific thread. Right now, we mix that between bottom halves and on_vcpu. > In some sense, the problem is that bottom halves conflate this service > _and_ idle callbacks, and that is the weird property. Idle callbacks > are used basically only for DMA, and real-world DMA does not have at > all the semantics that qemu_bh_schedule_idle provides (which in turn > is very tricky and not exactly what comments in qemu_bh_update_timeout > promise). I think before we can do any major surgery, we need to redo the way that legacy DMA is handled so that it doesn't require constant polling as it does now. Regards, Anthony Liguori