From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TELFe-00041C-4y for qemu-devel@nongnu.org; Wed, 19 Sep 2012 10:27:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TELFY-0002To-4u for qemu-devel@nongnu.org; Wed, 19 Sep 2012 10:27:42 -0400 Received: from david.siemens.de ([192.35.17.14]:19176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TELFX-0002TD-Ql for qemu-devel@nongnu.org; Wed, 19 Sep 2012 10:27:36 -0400 Message-ID: <5059D654.6080206@siemens.com> Date: Wed, 19 Sep 2012 16:27:32 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1348000626-16129-1-git-send-email-aliguori@us.ibm.com> <5059738E.5070004@redhat.com> <505977CD.7000404@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] qemu-clock: add an alarm timer based on timerfd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Portante Cc: "qemu-devel@nongnu.org" Please turn of HTML in you mailer. It's very hard to parse your reply. On 2012-09-19 16:15, Peter Portante wrote: > On Wed, Sep 19, 2012 at 3:44 AM, Jan Kiszka > wrote: > On 2012-09-19 09:26, Paolo Bonzini wrote: >> Il 18/09/2012 22:37, Anthony Liguori ha scritto: >>> Unfortunately, there's a lot of Windows code in qemu-timer.c and main= -loop.c >>> right now otherwise the refactoring would be trivial. I'll leave tha= t for >>> another day. >>> >>> Cc: Paolo Bonzini > >>> Cc: Jan Kiszka = > >>> Signed-off-by: Anthony Liguori > >>> --- >>> Please note, this is lightly tested. Since this is such a fundamenta= l change, >>> I'd like to do some performance analysis before committing but wanted= to share >>> early. >> >> Looks good. I think Peter Portante tested something similar, and foun= d no big >> difference between the two. But it's a good thing and, in my opinion,= for >> non-timerfd OSes we should simply adjust the select() timeout and not = bother >> with signals. >=20 > What would be the advantage of timerfd over select? On Linux, both use > hrtimers (and low slack for RT processes). >=20 > I am not sure the comparison is timerfd v. select, but timerfd v signal= based timer (setitimer). The timerfd path allows you to integrate with s= elect/poll/epoll loops, where as signal based timers make that more diffi= cult. One can do the same thing with signalfd, but only for one signal, w= here as you can setup multiple timers at the expense of file descriptors. >=20 > Additionally, FWIW, select() has a resolution capped by its use of stru= ct timeval, which is microseconds, where timerfd_settime allows for nanos= econd resolution. < 1=B5s resolution is pointless, even on RT-hardened kernels with fast hardware underneath and when running natively. >=20 > I'm starting to like the > select/WaitForMultipleObjects pattern as it would allow to consolidate > over basically two versions of timers and simplify the code. >=20 > With timerfd, signalfd and eventfd, Linux seems to have provided all th= e coverage needed to make that happen. The advantage is that timers based on select/poll timeouts will allow to unify a lot of code for _all_ host platforms, i.e. even Windows. We still need to evaluate the precise impact and look for potentially missed limitations (aka: someone has to write patches and test them). But if there are no relevant ones, it should be the better architecture. That said, a timerfd based solution for Linux may be an intermediate step of the select-based work takes longer. Jan --=20 Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux