From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4WFJ-0007Nr-Pm for qemu-devel@nongnu.org; Thu, 23 Aug 2012 08:10:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4WFC-0001rQ-PM for qemu-devel@nongnu.org; Thu, 23 Aug 2012 08:10:45 -0400 Received: from goliath.siemens.de ([192.35.17.28]:30196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4WFC-0001qz-Fz for qemu-devel@nongnu.org; Thu, 23 Aug 2012 08:10:38 -0400 Message-ID: <50361DB9.20709@siemens.com> Date: Thu, 23 Aug 2012 14:10:33 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <503612B9.1070601@siemens.com> <5036168B.1000900@redhat.com> In-Reply-To: <5036168B.1000900@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH] qemu-timer: Run timers in alarm timer handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Weil , qemu-devel On 2012-08-23 13:39, Paolo Bonzini wrote: > Il 23/08/2012 13:23, Jan Kiszka ha scritto: >> No need for this indirection via qemu_notify_event. On Unix, we already >> catch SIGALRM via signalfd (or its emulation) and run the handler >> synchronously. Under Win32, handlers run in separate threads. So we just >> need to grab the global lock around the handler execution. >> >> Signed-off-by: Jan Kiszka >> --- >> >> The Unix side looks safe to me, but I'm not yet 100% confident about >> Win32. This is part of an ongoing effort to create separate alarm >> timers over their own io-threads. A lengthy effort. > > Can you expand on this? Well, this patch removes an indirection from timer event deliveries. So it reduces overhead, though only noticeable if you have high-rate timers. > > The Win32 bits look fine, but it's a bit scary to make the Unix and > Win32 paths so different. It works well until we have a BQL for timers, > but would this complicate shrinking the scope of the BQL? Nope, not yet. We continue to hold the BQL across qemu_run_all_timers. Under Unix, this happens as qemu_iohandler_poll->sigfd_handler-> host_alarm_handler runs under BQL, under win32 due to explicit locking. The plan is to only pull specifically marked alarm timers out of this standard path, in the future. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux