Re: [Qemu-devel] [PATCH] qemu-clock: add an alarm timer based on timerfd

[Avi Kivity <avi@redhat.com>]

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 <pbonzini@redhat.com>
>>> Cc: Jan Kiszka <jan.kiszka@siemens.com>
>>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>> ---
>>> 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