From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4X2e-00075R-Sq for qemu-devel@nongnu.org; Thu, 23 Aug 2012 09:01:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4X2R-0001XC-Mt for qemu-devel@nongnu.org; Thu, 23 Aug 2012 09:01:44 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4X2R-0001Wo-Ds for qemu-devel@nongnu.org; Thu, 23 Aug 2012 09:01:31 -0400 Message-ID: <503629A8.4070501@siemens.com> Date: Thu, 23 Aug 2012 15:01:28 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <503612B9.1070601@siemens.com> <5036168B.1000900@redhat.com> <50361DB9.20709@siemens.com> <503620F7.3050507@redhat.com> In-Reply-To: <503620F7.3050507@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 14:24, Paolo Bonzini wrote: > 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. Is there anything that requires this ordering for timers? > > 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. I'm not heading for multi-instance alarm timers or any kind of optimization on Windows. It should just continue to work. Windows is neither a high-performance nor a real-time platform for QEMU, IMHO. > > 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 Need to think about it. At least, real-time tasks will get proper precision on Linux. Not sure if it will be sufficient on other hosts. > (BTW, switching to an absolute deadline would be useful too). Why? We aren't affected by clock adjustment with relative timeouts. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux