From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4WSc-0000xL-Jz for qemu-devel@nongnu.org; Thu, 23 Aug 2012 08:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4WSb-0005yR-GQ for qemu-devel@nongnu.org; Thu, 23 Aug 2012 08:24:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4WSb-0005yF-93 for qemu-devel@nongnu.org; Thu, 23 Aug 2012 08:24:29 -0400 Message-ID: <503620F7.3050507@redhat.com> Date: Thu, 23 Aug 2012 14:24:23 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <503612B9.1070601@siemens.com> <5036168B.1000900@redhat.com> <50361DB9.20709@siemens.com> In-Reply-To: <50361DB9.20709@siemens.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: Jan Kiszka Cc: Stefan Weil , qemu-devel Il 23/08/2012 14:10, Jan Kiszka ha scritto: >> 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. Actually, timers (and bottom halves) are always run after iohandlers. So the qemu_notify_event should already be completely useless for Unix, even if we leave the host_alarm_handler indirection. But this leaves out Windows, where your next task of (IIUC) having multiple instances of struct qemu_alarm_timer would be complicated by the qemu_notify_event. I guess this is the original reason for your patch. So, in order to remove the qemu_notify_event completely, what about not using signals anymore for timers? You could just tweak the select timeout and drop all the -clock madness. Zero syscalls, practically no overhead. If this is not precise enough, use timerfd on Linux only (BTW, switching to an absolute deadline would be useful too). >> 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. Ok, thanks for clarifying. Paolo