Il 23/08/2012 20:09, Jan Kiszka ha scritto:
> On 2012-08-23 15:11, Paolo Bonzini wrote:
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,
On 2012-08-23 15:11, Paolo Bonzini wrote:
>>> 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 prec
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
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 b
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 t
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
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
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
-
