From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] Replacing (and removing) get_ticks_per_sec() function with NANOSECONDS_PER_SECOND Signed-off-by: Rutuja Shah Date: Fri, 11 Mar 2016 13:07:06 +0100 Message-ID: <56E2B4EA.4050305@redhat.com> References: <1457638209-14218-1-git-send-email-rutu.shah.26@gmail.com> <56E2AFA1.5010201@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: kraxel@redhat.com, samuel.thibault@ens-lyon.org, stefanha@redhat.com, kwolf@redhat.com, crosthwaite.peter@gmail.com, rth@twiddle.net, mst@redhat.com, imammedo@redhat.com, peter.maydell@linaro.org, balrogg@gmail.com, jsnow@redhat.com, alistair.francis@xilinx.com, agraf@suse.de, jasowang@redhat.com, blauwirbel@gmail.co, mark.cave-ayland@ilande.co.uk, cornelia.huck@de.ibm.com, lcapitulino@redhat.com, armbru@redhat.com, qemu-block@nongnu.org, qemu-arm@nongnu.org, qemu-ppc@nongnu.org, kvm@vger.kernel.org To: Christian Borntraeger , rutu.shah.26@gmail.com, qemu-devel@nongnu.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51031 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752073AbcCKMHS (ORCPT ); Fri, 11 Mar 2016 07:07:18 -0500 In-Reply-To: <56E2AFA1.5010201@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/03/2016 12:44, Christian Borntraeger wrote: >> - s->tick_offset_vmstate = s->tick_offset + delta / get_ticks_per_sec(); >> > + s->tick_offset_vmstate = s->tick_offset + delta / NANOSECONDS_PER_SECOND; > [...] > > While technically correct, I do not like these changes. The interfaces expect "ticks", > and the fact that this happens to be a nanosecond does not help regarding > readability. Actually, I think usage of "tick" in this file is just for historical reasons. A long time ago QEMU had a timer that ticked every millisecond and the timers were not in nanosecond precision; rather they used cpu_get_ticks() which was tied to the TSC. This was changed in 2006, and since then the number of ticks per second was changed to a constant 10^9. Usage of "tick" to represent nanoseconds is definitely the exception. It's much more common to have code like: now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); ... ticks = muldiv64(now, 32768, get_ticks_per_sec()); (hw/arm/omap1.c) that converts nanoseconds to 32768 Hz "ticks", and using get_ticks_per_sec() is very confusing in the latter example. You would think that get_ticks_per_sec() is in the numerator (second argument of muldiv64), not in the denominator! Most of the time, get_ticks_per_sec()'s result end up being massaged in some formula and passed to timer_mod which expects nanoseconds, such as timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + (get_ticks_per_sec() / 50)); where you have nanoseconds on the left of the plus sign and "ticks" on the right. NANOSECONDS_PER_SECOND makes it obvious that the timer will expire in 1/50th of a second. > If - for some reason - we want to replace a function with a MACRO, then > please introduce TICKS_PER_SECOND which just feels better when reading the code. This would be wrong, for the reason mentioned above. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeLqv-0006Hc-7M for qemu-devel@nongnu.org; Fri, 11 Mar 2016 07:07:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeLqu-0007XY-6u for qemu-devel@nongnu.org; Fri, 11 Mar 2016 07:07:33 -0500 References: <1457638209-14218-1-git-send-email-rutu.shah.26@gmail.com> <56E2AFA1.5010201@de.ibm.com> From: Paolo Bonzini Message-ID: <56E2B4EA.4050305@redhat.com> Date: Fri, 11 Mar 2016 13:07:06 +0100 MIME-Version: 1.0 In-Reply-To: <56E2AFA1.5010201@de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Replacing (and removing) get_ticks_per_sec() function with NANOSECONDS_PER_SECOND Signed-off-by: Rutuja Shah List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , rutu.shah.26@gmail.com, qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, kvm@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, mark.cave-ayland@ilande.co.uk, lcapitulino@redhat.com, kraxel@redhat.com, qemu-block@nongnu.org, agraf@suse.de, samuel.thibault@ens-lyon.org, alistair.francis@xilinx.com, qemu-arm@nongnu.org, stefanha@redhat.com, cornelia.huck@de.ibm.com, jsnow@redhat.com, rth@twiddle.net, kwolf@redhat.com, crosthwaite.peter@gmail.com, armbru@redhat.com, blauwirbel@gmail.co, qemu-ppc@nongnu.org, imammedo@redhat.com On 11/03/2016 12:44, Christian Borntraeger wrote: >> - s->tick_offset_vmstate =3D s->tick_offset + delta / get_ticks_per= _sec(); >> > + s->tick_offset_vmstate =3D s->tick_offset + delta / NANOSECONDS= _PER_SECOND; > [...] >=20 > While technically correct, I do not like these changes. The interfaces = expect "ticks", > and the fact that this happens to be a nanosecond does not help regardi= ng=20 > readability. Actually, I think usage of "tick" in this file is just for historical reasons. A long time ago QEMU had a timer that ticked every millisecond and the timers were not in nanosecond precision; rather they used cpu_get_ticks() which was tied to the TSC. This was changed in 2006, and since then the number of ticks per second was changed to a constant 10^9. Usage of "tick" to represent nanoseconds is definitely the exception. It's much more common to have code like: now =3D qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); ... ticks =3D muldiv64(now, 32768, get_ticks_per_sec()); (hw/arm/omap1.c) that converts nanoseconds to 32768 Hz "ticks", and using get_ticks_per_sec() is very confusing in the latter example. You would think that get_ticks_per_sec() is in the numerator (second argument of muldiv64), not in the denominator! Most of the time, get_ticks_per_sec()'s result end up being massaged in some formula and passed to timer_mod which expects nanoseconds, such as timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + (get_ticks_per_sec() / 50)); where you have nanoseconds on the left of the plus sign and "ticks" on the right. NANOSECONDS_PER_SECOND makes it obvious that the timer will expire in 1/50th of a second. > If - for some reason - we want to replace a function with a MACRO, then > please introduce TICKS_PER_SECOND which just feels better when reading = the code. This would be wrong, for the reason mentioned above. Paolo