qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC][PATCH] qemu-timer: Run timers in alarm timer handler
Date: Thu, 23 Aug 2012 14:24:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

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.

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.

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
(BTW, switching to an absolute deadline would be useful too).

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

Ok, thanks for clarifying.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]