From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCFgN-0003LF-Lt for qemu-devel@nongnu.org; Thu, 13 Sep 2012 16:06:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCFgC-0000fn-LD for qemu-devel@nongnu.org; Thu, 13 Sep 2012 16:06:39 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:64810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCFgC-0000fh-G9 for qemu-devel@nongnu.org; Thu, 13 Sep 2012 16:06:28 -0400 Received: by obbta14 with SMTP id ta14so4792296obb.4 for ; Thu, 13 Sep 2012 13:06:27 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20120913185600.GG25041@redhat.com> References: <20120913104940.GA20907@redhat.com> <5051DC20.4090204@redhat.com> <20120913132804.GO7767@redhat.com> <87r4q6xbiy.fsf@codemonkey.ws> <20120913142228.GK20907@redhat.com> <87boha7zyx.fsf@codemonkey.ws> <20120913144811.GL20907@redhat.com> <87ehm5or07.fsf@codemonkey.ws> <20120913160613.GF25041@redhat.com> <87392l7oxw.fsf@codemonkey.ws> <20120913185600.GG25041@redhat.com> Date: Thu, 13 Sep 2012 15:06:23 -0500 Message-ID: <87r4q5ads0.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Rethinking missed tick catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, Jan Kiszka , Michael Roth , Luiz Capitulino , Avi Kivity , Paolo Bonzini , Eric Blake Gleb Natapov writes: >> That's a bug. >> >> The next period calculation should not be based on the last period + >> length of period but rather on the current time + delta to next period >> boundary. >> > I disagree that this is a bug. This is by design to account for timer > signals that was delivered to late. It's immediate reinjection of ticks missed due to timer delay such that even if you select tdf=slew, you're still doing reinject. Maybe it's just semantics of whether it's a bug or feature, but hopefully you agree that making tdf=slew gradually deliver those missed ticks would be a good thing. > > >> IOW, if we shouldn't arm timers to expire backwards in time from when >> the event occurred. That should be accounted as a missed tick. >> > Not all users of qemu_timer have their own missed tick accounting so > qemu_timer provides general one. We can create another time source > for qemu_timer without this behaviour and use it in RTC. I think we probably should start by getting one device to have good catchup behavior and then we can look at generalizing. There are other things we've never done that would help too (like allowing for non-base 10 timer frequencies) that would make some of the time calculations easier. But I think at this point, I need to send some patches which requires some hacking first.. Regards, Anthony Liguori > > > -- > Gleb.