qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] qemu-clock: add an alarm timer based on timerfd
Date: Wed, 19 Sep 2012 19:55:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

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 <address@hidden>
>>> Cc: Jan Kiszka <address@hidden>
>>> Signed-off-by: Anthony Liguori <address@hidden>
>>> ---
>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]