From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uyizf-0002nD-07 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 09:39:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uyizd-0005rO-Q6 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 09:39:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uyizd-0005rC-EU for qemu-devel@nongnu.org; Mon, 15 Jul 2013 09:39:09 -0400 Message-ID: <51E3FB47.90308@redhat.com> Date: Mon, 15 Jul 2013 15:38:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373027986-17868-1-git-send-email-stefanha@redhat.com> <51D7079A.2000907@siemens.com> <51E3EEDA.4080501@redhat.com> <51E3F1C5.6030602@siemens.com> In-Reply-To: <51E3F1C5.6030602@siemens.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/3] qemu-timer: make QEMUTimer functions thread-safe List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "alex@alex.org.uk" , Anthony Liguori , "qemu-devel@nongnu.org" , Stefan Hajnoczi , "rth@twiddle.net" Il 15/07/2013 14:57, Jan Kiszka ha scritto: > On 2013-07-15 14:45, Paolo Bonzini wrote: >> Il 05/07/2013 19:51, Jan Kiszka ha scritto: >>> On 2013-07-05 14:39, Stefan Hajnoczi wrote: >>>> This series makes the following functions thread-safe: >>>> >>>> qemu_mod_timer_ns() >>>> qemu_mod_timer() >>>> qemu_del_timer() >>>> qemu_timer_pending() >>>> >>>> The following were already thread-safe: >>>> >>>> qemu_free_timer() >>>> qemu_new_timer() >>>> qemu_timer_expired() >>>> >>>> Now it is possible to use QEMUTimer outside the QEMU global mutex. Timer >>>> callbacks are still invoked from the main loop. If a thread wishes to run >>>> timer callbacks it must use a thread-safe QEMUBH (which Ping Fan Liu is working >>>> on). >>> >>> What do you mean with this? We need main-loop independent timers for any >>> task that depends on timely alarm delivery. Do your patches keep this in >>> mind as well? >> >> These are orthogonal issues. Stefan's usecase does not need timely >> delivery. > > Not necessarily. Timely delivery is likely the harder requirement that > also fulfills the need to move timer setup/manipulation outside of BQL. > I didn't have time to look into details yet, but there is a risk that > this rework will not help to achieve RT qualities Not a risk, a certainty. :) > but rather needs another, non-orthogonal rework. If you consider the "timers as a library" approach from your presentation at last year's KVM Forum, this series does nothing to help that goal. But it also does nothing to hinder it (all it does is add a mutex, basically), which is why I said it is orthogonal. Paolo