On 2012-08-23 13:39, Paolo Bonzini wrote: > Il 23/08/2012 13:23, Jan Kiszka ha scritto: >> No need for this indirection via qemu_notify_event. On Unix, we already >> catch SIGALRM via signalfd (or its emulation) and run the handler >> synchronously. Under Win32, handlers run in separate threads. So we just >> need to grab the global lock around the handler execution. >> >> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> >> --- >> >> The Unix side looks safe to me, but I'm not yet 100% confident about >> Win32. This is part of an ongoing effort to create separate alarm >> timers over their own io-threads. A lengthy effort. > > 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. > > The Win32 bits look fine, but it's a bit scary to make the Unix and > Win32 paths so different. It works well until we have a BQL for timers, > but would this complicate shrinking the scope of the BQL? Nope, not yet. We continue to hold the BQL across qemu_run_all_timers. Under Unix, this happens as qemu_iohandler_poll->sigfd_handler-> host_alarm_handler runs under BQL, under win32 due to explicit locking. The plan is to only pull specifically marked alarm timers out of this standard path, in the future. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
