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