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: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC][PATCH] qemu-timer: Run timers in alarm timer handler
Date: Thu, 23 Aug 2012 14:10:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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 <address@hidden>
>> ---
>>
>> 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



reply via email to

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