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 > <jan.kis...@siemens.com<mailto:jan.kis...@siemens.com>> 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 that for >>> another day. >>> >>> Cc: Paolo Bonzini <pbonz...@redhat.com<mailto:pbonz...@redhat.com>> >>> Cc: Jan Kiszka <jan.kis...@siemens.com<mailto:jan.kis...@siemens.com>> >>> Signed-off-by: Anthony Liguori >>> <aligu...@us.ibm.com<mailto:aligu...@us.ibm.com>> >>> --- >>> Please note, this is lightly tested. Since this is such a fundamental >>> 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 found 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. > > What would be the advantage of timerfd over select? On Linux, both use > hrtimers (and low slack for RT processes). > > 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 > select/poll/epoll loops, where as signal based timers make that more > difficult. One can do the same thing with signalfd, but only for one signal, > where as you can setup multiple timers at the expense of file descriptors. > > Additionally, FWIW, select() has a resolution capped by its use of struct > timeval, which is microseconds, where timerfd_settime allows for nanosecond > resolution.
< 1µs resolution is pointless, even on RT-hardened kernels with fast hardware underneath and when running natively. > > 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. > > With timerfd, signalfd and eventfd, Linux seems to have provided all the > 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 -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
