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 15:01:28 +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 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



reply via email to

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