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

[Jan Kiszka <jan.kiszka@siemens.com>]

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?

> 
> 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.

> 
> 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.

> (BTW, switching to an absolute deadline would be useful too).

Why? We aren't affected by clock adjustment with relative timeouts.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux