From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIGhP-0003nf-E3 for qemu-devel@nongnu.org; Sun, 10 Jan 2016 09:10:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIGhO-0004lR-KA for qemu-devel@nongnu.org; Sun, 10 Jan 2016 09:10:27 -0500 References: <9bdf3e1d349c7cfc6d75cc37430fe4f177c20734.1452359845.git.digetx@gmail.com> From: Dmitry Osipenko Message-ID: <56926634.8090507@gmail.com> Date: Sun, 10 Jan 2016 17:09:56 +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 v10 2/7] 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 10.01.2016 03:44, Peter Crosthwaite пишет: > On Sat, Jan 9, 2016 at 9:39 AM, Dmitry Osipenko wrote: >> ptimer_get_count() might be called while QEMU timer already been expired. >> In that case ptimer would return counter = 0, which might be undesirable >> in case of polled timer. Do counter wrap around for periodic timer to keep >> it distributed. In order to achieve more accurate emulation behaviour of >> certain hardware, don't perform wrap around when in icount mode and return >> counter = 0 in that case (that doesn't affect polled counter distribution). >> >> In addition, there is no reason to keep expired timer tick deferred, so >> just perform the tick from ptimer_get_count(). >> >> Signed-off-by: Dmitry Osipenko >> --- >> hw/core/ptimer.c | 26 +++++++++++++++++++------- >> 1 file changed, 19 insertions(+), 7 deletions(-) >> >> diff --git a/hw/core/ptimer.c b/hw/core/ptimer.c >> index c3d31cb..cf329eb 100644 >> --- a/hw/core/ptimer.c >> +++ b/hw/core/ptimer.c >> @@ -83,14 +83,17 @@ static void ptimer_tick(void *opaque) >> >> uint64_t ptimer_get_count(ptimer_state *s) >> { >> - int64_t now; >> + int enabled = s->enabled; > > You haven't added any additional usages of s->enabled to really > warrant the new local variable, I think it should just stay as > s->enabled to avoid churn. > Compiler doesn't know that ptimer struct is supposed to be thread-safe there and infers memory load instructions rather than use pure cpu registers. Local variable would help to produce somewhat more rational. However, given how optimized and complex modern cpu's, I'm not really sure that it would bring any benefit and agree that it might not worth churning. Thanks for review! -- Dmitry