[Top][All Lists]
[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
Re: [Qemu-devel] [PATCH] qemu-clock: add an alarm timer based on timerfd, Peter Portante, 2012/09/19