From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TENYY-0007x1-Ll for qemu-devel@nongnu.org; Wed, 19 Sep 2012 12:55:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TENYU-0005ML-DU for qemu-devel@nongnu.org; Wed, 19 Sep 2012 12:55:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TENYU-0005LK-3Q for qemu-devel@nongnu.org; Wed, 19 Sep 2012 12:55:18 -0400 Message-ID: <5059F8F0.4040902@redhat.com> Date: Wed, 19 Sep 2012 19:55:12 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1348000626-16129-1-git-send-email-aliguori@us.ibm.com> <5059738E.5070004@redhat.com> <505977CD.7000404@siemens.com> In-Reply-To: <505977CD.7000404@siemens.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: Jan Kiszka Cc: Paolo Bonzini , Anthony Liguori , "qemu-devel@nongnu.org" , Peter Portante , Stefan Weil On 09/19/2012 10:44 AM, Jan Kiszka wrote: > 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. An advantage is that if you have a lot of fd events but fewer timer events, then you do not need to rearm the timer needlessly. It just waits in the background. I doubt whether that advantage amounts to anything in practice. -- error compiling committee.c: too many arguments to function