From: w@1wt.eu (Willy Tarreau)
To: linux-arm-kernel@lists.infradead.org
Subject: Guarantee udelay(N) spins at least N microseconds
Date: Fri, 10 Apr 2015 13:42:53 +0200 [thread overview]
Message-ID: <20150410114253.GA18645@1wt.eu> (raw)
In-Reply-To: <5527B331.5000205@free.fr>
Hi,
On Fri, Apr 10, 2015 at 01:25:37PM +0200, Mason wrote:
> Hello everyone,
>
> This is take 2 of my tiny delay.c patch
>
> Problem statement
>
> When converting microseconds to timer cycles in __timer_udelay() and
> __timer_const_udelay(), the result is rounded down(*), which means the
> system will not spin as long as requested (specifically, between
> epsilon and 1 cycle shorter).
>
> If I understand correctly, most drivers expect udelay(N) to spin for
> at least N ?s. Is that correct? In that use case, spinning less might
> introduce subtle heisenbugs.
>
>
> Typical example
>
> timer->freq = 90 kHz && HZ = 100
> (thus UDELAY_MULT = 107374 && ticks_per_jiffy = 900)
>
> udelay(10) => __timer_const_udelay(10*107374)
> => __timer_delay((1073740*900) >> 30)
> => __timer_delay(0)
>
> So udelay(10) resolves to no delay at all.
>
>
> (*) 2^41 / 10^6 = 2199023,255552
> 2199023 < 2^41 / 10^6
> UDELAY_MULT = 2199023*HZ / 2^11 < 2^30*HZ / 10^6
>
> cycles = N * UDELAY_MULT * freq/HZ / 2^30
> < N * 2^30*HZ / 10^6 * freq/HZ / 2^30
> < N / 10^6 * freq
>
>
> Proposed fix
>
> Since results are always rounded down, all we need is to increment
> the result by 1 to round it up.
>
> Would someone ACK the patch below?
>
> Regards.
>
>
> Patch against 4.0-rc4
>
> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> index 312d43e..3cfbd07 100644
> --- a/arch/arm/lib/delay.c
> +++ b/arch/arm/lib/delay.c
> @@ -66,7 +66,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);
> }
If loops is a multiple of 2 ^ UDELAY_SHIFT, then your result is too
high by one. The proper way to round by excess is the following :
__timer_delay((loops + (1 << UDELAY_SHIFT) - 1) >> UDELAY_SHIFT);
That way it does +1 for every value of loop not an exact multiple
of 2^UDELAY_SHIFT.
Regards,
willy
next prev parent reply other threads:[~2015-04-10 11:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 11:25 Guarantee udelay(N) spins at least N microseconds Mason
2015-04-10 11:42 ` Willy Tarreau [this message]
2015-04-10 14:53 ` Mason
2015-04-10 15:06 ` Willy Tarreau
2015-04-10 11:44 ` Russell King - ARM Linux
2015-04-10 12:41 ` Mason
2015-04-10 15:06 ` Russell King - ARM Linux
2015-04-10 15:30 ` Mason
2015-04-10 16:08 ` Russell King - ARM Linux
2015-04-10 20:01 ` Mason
2015-04-10 20:42 ` Russell King - ARM Linux
2015-04-10 21:22 ` Mason
2015-04-11 7:30 ` Russell King - ARM Linux
2015-04-11 11:57 ` Mason
2015-04-11 12:10 ` Russell King - ARM Linux
2015-04-11 13:45 ` Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150410114253.GA18645@1wt.eu \
--to=w@1wt.eu \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).