From patchwork Thu Apr 2 12:12:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mason X-Patchwork-Id: 6147351 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 451F49F2EC for ; Thu, 2 Apr 2015 12:15:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 58E3520396 for ; Thu, 2 Apr 2015 12:15:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 217B320392 for ; Thu, 2 Apr 2015 12:15:34 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YddzA-00008Y-1V; Thu, 02 Apr 2015 12:12:36 +0000 Received: from smtp2-g21.free.fr ([2a01:e0c:1:1599::11]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Yddz4-0008TJ-Vf for linux-arm-kernel@lists.infradead.org; Thu, 02 Apr 2015 12:12:32 +0000 Received: from [172.27.0.114] (unknown [83.142.147.193]) (Authenticated sender: shill) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 809034B024F for ; Thu, 2 Apr 2015 14:10:08 +0200 (CEST) Message-ID: <551D3215.6030102@free.fr> Date: Thu, 02 Apr 2015 14:12:05 +0200 From: Mason User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Linux ARM Subject: Re: __timer_udelay(1) may return immediately References: <551D0C71.8050707@free.fr> In-Reply-To: <551D0C71.8050707@free.fr> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150402_051231_195254_CA04AF58 X-CRM114-Status: GOOD ( 18.59 ) X-Spam-Score: -0.7 (/) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 02/04/2015 11:31, Mason wrote: > I'm using timer-based delays from arch/arm/lib/delay.c > > Consider the following configuration: > HZ=100 > timer->freq = 1000000 > > Thus > UDELAY_MULT = 107374 > ticks_per_jiffy = 10000 > > Thus __timer_udelay(1) => > __timer_const_udelay(107374) => > __timer_delay(0) => calls get_cycles() twice then returns prematurely > > The issue comes from a tiny rounding error as > 107374 * ticks_per_jiffy >> UDELAY_SHIFT = 0,9999983 > which is rounded down to 0. > > The root of the issue is that mathematically, > UDELAY_MULT = 2199023 * HZ / 2048 = 107374,169921875 > which is rounded down to 107374. > > It seems to me that a simple solution would be to round > UDELAY_MULT up instead of down. > > Thus UDELAY_MULT = 107375 > 107375 * ticks_per_jiffy >> UDELAY_SHIFT = 1,0000076 > > We might end up sleeping one cycle more than necessary, but I don't > think spinning a bit longer would be a problem? > > Patch provided for illustration purposes. > > What do you think? > > Regards. > > > diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h > index dff714d..873a43e 100644 > --- a/arch/arm/include/asm/delay.h > +++ b/arch/arm/include/asm/delay.h > @@ -10,7 +10,7 @@ > #include /* HZ */ > > #define MAX_UDELAY_MS 2 > -#define UDELAY_MULT ((UL(2199023) * HZ) >> 11) > +#define UDELAY_MULT (((UL(2199023) * HZ) >> 11) + 1) > #define UDELAY_SHIFT 30 > > #ifndef __ASSEMBLY__ Come to think of it, a closely related issue is: what to do when the user requests a delay which resolves to a cycle count with a non-zero fractional part? (e.g. delay for 7.2 cycles) I think we should round up these values (delay for 8 cycles in the example). So forget the first patch, keep the rounded down value for UDELAY_MULT, and round up the cycle count. Also, I was thinking of implementing ndelay() in delay.h Would it make sense to define #define NSDELAY_MULT ((UL(281475) * HZ) >> 18) // or perhaps 281474? and have ndelay(ns) resolve __const_udelay((ns) * NSDELAY_MULT)) Or should I just keep that in platform-specific headers? Regards. diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c index 5306de3..a9b3c75 100644 --- a/arch/arm/lib/delay.c +++ b/arch/arm/lib/delay.c @@ -59,7 +59,7 @@ static void __timer_const_udelay(unsigned long xloops) { unsigned long long loops = xloops; loops *= arm_delay_ops.ticks_per_jiffy; - __timer_delay(loops >> UDELAY_SHIFT); + __timer_delay((loops >> UDELAY_SHIFT) + 1); } static void __timer_udelay(unsigned long usecs)