From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEExI-0004io-GY for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:44:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEExH-0003Gw-BW for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:44:20 -0400 Received: from goliath.siemens.de ([192.35.17.28]:21322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEExH-0003Gg-1l for qemu-devel@nongnu.org; Wed, 19 Sep 2012 03:44:19 -0400 Message-ID: <505977CD.7000404@siemens.com> Date: Wed, 19 Sep 2012 09:44:13 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1348000626-16129-1-git-send-email-aliguori@us.ibm.com> <5059738E.5070004@redhat.com> In-Reply-To: <5059738E.5070004@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu-clock: add an alarm timer based on timerfd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Weil , Anthony Liguori , "qemu-devel@nongnu.org" , Peter Portante On 2012-09-19 09:26, Paolo Bonzini wrote: > Il 18/09/2012 22:37, Anthony Liguori ha scritto: >> Unfortunately, there's a lot of Windows code in qemu-timer.c and main-loop.c >> right now otherwise the refactoring would be trivial. I'll leave that for >> another day. >> >> Cc: Paolo Bonzini >> Cc: Jan Kiszka >> Signed-off-by: Anthony Liguori >> --- >> Please note, this is lightly tested. Since this is such a fundamental change, >> I'd like to do some performance analysis before committing but wanted to share >> early. > > Looks good. I think Peter Portante tested something similar, and found no big > difference between the two. But it's a good thing and, in my opinion, for > non-timerfd OSes we should simply adjust the select() timeout and not bother > with signals. What would be the advantage of timerfd over select? On Linux, both use hrtimers (and low slack for RT processes). I'm starting to like the select/WaitForMultipleObjects pattern as it would allow to consolidate over basically two versions of timers and simplify the code. Jan > > I'm not sure if the same can be done for Windows, but I think it's possible as long > as you keep the timeBeginPeriod/timeEndPeriod calls. As a start, Stefan, can you > check if the win32 timer works for you with the calls added? Like this: > > diff --git a/qemu-timer.c b/qemu-timer.c > index c7a1551..721c769 100644 > --- a/qemu-timer.c > +++ b/qemu-timer.c > @@ -673,6 +673,10 @@ static int win32_start_timer(struct qemu_alarm_timer *t) > HANDLE hTimer; > BOOLEAN success; > > + timeGetDevCaps(&mm_tc, sizeof(mm_tc)); > + > + timeBeginPeriod(mm_tc.wPeriodMin); > + > /* If you call ChangeTimerQueueTimer on a one-shot timer (its period > is zero) that has already expired, the timer is not updated. Since > creating a new timer is relatively expensive, set a bogus one-hour > @@ -688,6 +692,7 @@ static int win32_start_timer(struct qemu_alarm_timer *t) > if (!success) { > fprintf(stderr, "Failed to initialize win32 alarm timer: %ld\n", > GetLastError()); > + timeEndPeriod(mm_tc.wPeriodMin); > return -1; > } > > @@ -702,6 +707,7 @@ static void win32_stop_timer(struct qemu_alarm_timer *t) > if (hTimer) { > DeleteTimerQueueTimer(NULL, hTimer, NULL); > } > + timeEndPeriod(mm_tc.wPeriodMin); > } > > static void win32_rearm_timer(struct qemu_alarm_timer *t, > > Paolo > -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux