Re: [Qemu-devel] [RFC][PATCH] qemu-timer: Run timers in alarm timer handler

[Paolo Bonzini]

Il 23/08/2012 15:01, Jan Kiszka ha scritto:
> On 2012-08-23 14:24, Paolo Bonzini wrote:
>> Il 23/08/2012 14:10, Jan Kiszka ha scritto:
>>>> Can you expand on this?
>>>
>>> Well, this patch removes an indirection from timer event deliveries. So
>>> it reduces overhead, though only noticeable if you have high-rate timers.
>>
>> Actually, timers (and bottom halves) are always run after iohandlers.
>> So the qemu_notify_event should already be completely useless for Unix,
>> even if we leave the host_alarm_handler indirection.
> 
> Is there anything that requires this ordering for timers?

No, I don't think so.  (And also not for bottom halves, since those
always do a qemu_notify_event).

>> But this leaves out Windows, where your next task of (IIUC) having
>> multiple instances of struct qemu_alarm_timer would be complicated by
>> the qemu_notify_event.  I guess this is the original reason for your patch.
> 
> I'm not heading for multi-instance alarm timers or any kind of
> optimization on Windows. It should just continue to work. Windows is
> neither a high-performance nor a real-time platform for QEMU, IMHO.

Yeah, making multi-instance alarm timers optional does it as well.  (As
long as it doesn't bit rot).

>> So, in order to remove the qemu_notify_event completely, what about not
>> using signals anymore for timers?  You could just tweak the select
>> timeout and drop all the -clock madness.  Zero syscalls, practically no
>> overhead.  If this is not precise enough, use timerfd on Linux only
> 
> Need to think about it. At least, real-time tasks will get proper
> precision on Linux. Not sure if it will be sufficient on other hosts.

Do we care (I put non-Linux POSIX just a little above Windows but not much)?

>> (BTW, switching to an absolute deadline would be useful too).
> 
> Why? We aren't affected by clock adjustment with relative timeouts.

Just the usual fact that the deadline is incorrect if QEMU is pre-empted
between computing the deadline and applying it.  It shouldn't really
matter for the iothread, because it's not CPU bound, but it's cleaner
since internally we store absolute deadlines anyway.

Paolo