From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1INyMW-0000iU-SH for qemu-devel@nongnu.org; Wed, 22 Aug 2007 18:07:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1INyMV-0000e9-3J for qemu-devel@nongnu.org; Wed, 22 Aug 2007 18:07:40 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1INyMV-0000dw-09 for qemu-devel@nongnu.org; Wed, 22 Aug 2007 18:07:39 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1INyMU-0005IN-De for qemu-devel@nongnu.org; Wed, 22 Aug 2007 18:07:38 -0400 Received: by rv-out-0910.google.com with SMTP id c27so266556rvf for ; Wed, 22 Aug 2007 15:07:37 -0700 (PDT) Message-ID: <68676e00708221507k206c1805v1ea074f4b660c769@mail.gmail.com> Date: Thu, 23 Aug 2007 00:07:37 +0200 From: Luca In-Reply-To: <64F9B87B6B770947A9F8391472E032160D5042F3@ehost011-8.exch011.intermedia.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070817231149.544849769@gmail.com> <20070821193834.GB13544@dreamland.darkstar.lan> <46CBC34F.6060601@qumranet.com> <20070822161211.GA30147@dreamland.darkstar.lan> <46CC6285.3090904@qumranet.com> <68676e00708220938y57c07edas705fc8360aefcb78@mail.gmail.com> <46CC680C.1030307@qumranet.com> <68676e00708221023m352c2de3y3b19188dbb9ef49e@mail.gmail.com> <68676e00708221221n6f8fcd67m9d15f7fea663ec71@mail.gmail.com> <64F9B87B6B770947A9F8391472E032160D5042F3@ehost011-8.exch011.intermedia.net> Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dor Laor Cc: Dan Kenigsberg , Avi Kivity , kvm-devel@lists.sf.net, qemu-devel@nongnu.org On 8/22/07, Dor Laor wrote: > >> > >>> This is QEMU, with dynticks and HPET: > >> > >>> > >> > >>> % time seconds usecs/call calls errors syscall > >> > >>> ------ ----------- ----------- --------- --------- > ------------- > >--- > >> > >>> 52.10 0.002966 0 96840 > clock_gettime > >> > >>> 19.50 0.001110 0 37050 > timer_gettime > >> > >>> 10.66 0.000607 0 20086 > timer_settime > >> > >>> 10.40 0.000592 0 8985 2539 sigreturn > >> > >>> 4.94 0.000281 0 8361 2485 select > >> > >>> 2.41 0.000137 0 8362 gettimeofday > >> > >>> ------ ----------- ----------- --------- --------- > ------------- > >--- > >> > >>> 100.00 0.005693 179684 5024 total > >> > >>> > >> > >>> > >> > >> This looks like 250 Hz? > >> > >> > >> > > > >> > > Nope: > >> > > > >> > > # CONFIG_NO_HZ is not set > >> > > # CONFIG_HZ_100 is not set > >> > > # CONFIG_HZ_250 is not set > >> > > # CONFIG_HZ_300 is not set > >> > > CONFIG_HZ_1000=y > >> > > CONFIG_HZ=1000 > >> > > > >> > > and I'm reading it from /proc/config.gz on the guest. > >> > > > >> > > >> > Yeah, thought so -- so dyntick is broken at present. > >> > >> I see a lot of sub ms timer_settime(). Many of them are the result of > >> ->expire_time being less than the current qemu_get_clock(). This > >> results into 250us timer due to MIN_TIMER_REARM_US; this happens only > >> for the REALTIME timer. Other sub-ms timers are generated by the > >> VIRTUAL timer. > >> > >> This first issue is easily fixed; if expire_time < current time then > >> the timer has expired and hasn't been reprogrammed (and thus can be > >> ignored). > >> VIRTUAL just becomes more accurate with dyntics, before multiple > >> timers were batched together. > >> > >> > Or maybe your host kernel can't support such a high rate. > >> > >> I don't know... a simple printf tells me that the signal handler is > >> called about 1050 times per second, which sounds about right. > > > >...unless strace is attached. ptrace()'ing the process really screw up > >the timing with dynticks; HPET is also affected but the performance > >hit is not as severe. > > > I didn't figure out how you use both hpet and dyn-tick together. I don't. Only one timer source is active at any time; the selection is done at startup with -clock option. > Hpet has periodic timer while dyn-tick is one shot timer each time. > Is ther a chance that both are working and that's the source of our > problems? No, the various sources are exclusive (though it might be possible to use HPET in one shot mode). Luca