From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGv4R-0000K4-Ur for qemu-devel@nongnu.org; Wed, 06 Jan 2016 15:52:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGv4Q-0002Za-Tz for qemu-devel@nongnu.org; Wed, 06 Jan 2016 15:52:39 -0500 References: <004073b3af0a56899f9a07e3f6b00167359322e6.1451960508.git.digetx@gmail.com> <20160106121711.GC4227@pcrost-box> <568D12A7.3010304@gmail.com> From: Dmitry Osipenko Message-ID: <568D7E7B.8090505@gmail.com> Date: Wed, 6 Jan 2016 23:52:11 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v8 2/4] hw/ptimer: Perform tick and counter wrap around if timer already expired List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , qemu-arm , QEMU Developers 06.01.2016 16:59, Peter Crosthwaite пишет: >>>> + >>>> + if (expired) { >>>> + /* Wrap around periodic counter. */ >>>> + counter = s->delta = s->limit - counter % s->limit; >>> >>> >>> Why do you update the delta here? >>> >> >> Because we would want to schedule next tick based on current wrapped around >> counter value and not some arbitrary delta. >> > > So looking at ptimer_reload(), the new schedule is done relative to > the VM clock of the when the tick was expected to hit, not the current > time. But this new delta is going to be relative to the now time and > then used to update the next tick which will happen relative to > next_event. Unless you stop or scale the timer, I don't think you need > to do delta manipulation? > Yes, I missed that next_event would be set earlier (like you described) in case of expired timer. Thanks for the note, will fix it. >>> Also can you just get ptimer_reload to do the modulo math for you? If the >>> timer is !oneshot and expired, then you call ptimer_reload anyway, >>> which will update next_event. When the expired test returns false >>> you can just reliably use the original logic involving now and next. >>> >> >> Yes, that's what I changed in V9. Have you received it? >> >> https://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg00272.html >> > > Just had a look. > > V9 still has the modulo I think?: > > + if (expired && (counter != 0)) { > + /* Wrap around periodic counter. */ > + counter = s->delta = s->limit - counter % s->limit; > + } > Modulo is there, I just meant that V9 changed to call ptimer_reload() on counter == 0. As noted above, ptimer_reload would adjust next_event, so s->delta shouldn't be set to the wrapped around counter. However it should be set to the limit, since delta might been altered by ptimer_set_count. -- Dmitry