From: slash.tmp@free•fr (Mason)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arm: spin one more cycle in timer-based delays
Date: Fri, 18 Nov 2016 13:24:53 +0100 [thread overview]
Message-ID: <582EF315.2060707@free.fr> (raw)
In-Reply-To: <20161118120630.GJ13470@arm.com>
On 18/11/2016 13:06, Will Deacon wrote:
> On Tue, Nov 15, 2016 at 02:36:33PM +0100, Mason wrote:
>
>> When polling a tick counter in a busy loop, one might sample the
>> counter just *before* it is updated, and then again just *after*
>> it is updated. In that case, while mathematically v2-v1 equals 1,
>> only epsilon has really passed.
>>
>> So, if a caller requests an N-cycle delay, we spin until v2-v1
>> is strictly greater than N to avoid these random corner cases.
>>
>> Signed-off-by: Mason <slash.tmp@free•fr>
>> ---
>> arch/arm/lib/delay.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
>> index 69aad80a3af4..3f1cd15ca102 100644
>> --- a/arch/arm/lib/delay.c
>> +++ b/arch/arm/lib/delay.c
>> @@ -60,7 +60,7 @@ static void __timer_delay(unsigned long cycles)
>> {
>> cycles_t start = get_cycles();
>>
>> - while ((get_cycles() - start) < cycles)
>> + while ((get_cycles() - start) <= cycles)
>> cpu_relax();
>> }
>
> I thought a bit about this last night. It is well known that the delay
> routines are not guaranteed to be accurate, and I don't *think* that's
> limited to over-spinning, so arguably this isn't a bug. However, taking
> the approach that "drivers should figure it out" is also unhelpful,
> because the frequency of the underlying counter isn't generally known
> and so drivers can't simply adjust the delay parameter.
>
> If you want to go ahead with this change, I do think that you should fix
> the other architectures for consistency (particularly arm64, which is
> likely to share drivers with arch/arm/). However, given that I don't
> think you've seen a failure in practice, it might be a hard sell to get
> the patches picked up, especially given the deliberately vague guarantees
> offered by the delay loop.
Hello Will,
Thanks for the in-depth analysis.
This is, conceptually, the first patch in a 2-patch series, and perhaps
the intent would have been clearer had I posted the series, along with
full rationale in the cover letter. I'll do that next week, so everyone
can judge with all the information in hand.
Regards.
next prev parent reply other threads:[~2016-11-18 12:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 13:36 [PATCH] arm: spin one more cycle in timer-based delays Mason
2016-11-18 12:06 ` Will Deacon
2016-11-18 12:24 ` Mason [this message]
2016-11-18 12:54 ` Russell King - ARM Linux
2016-11-18 14:18 ` Mason
2016-11-18 14:42 ` Peter Zijlstra
2016-11-18 17:51 ` Mason
2016-11-19 7:17 ` Afzal Mohammed
2016-11-19 11:03 ` Russell King - ARM Linux
2016-11-19 18:29 ` Mason
2016-11-20 19:18 ` Doug Anderson
2016-11-20 19:44 ` Russell King - ARM Linux
2016-11-20 20:00 ` Mason
2016-11-20 6:15 ` Afzal Mohammed
2016-11-20 19:15 ` Doug Anderson
2016-11-18 17:13 ` Doug Anderson
2016-11-18 17:32 ` Russell King - ARM Linux
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=582EF315.2060707@free.fr \
--to=slash.tmp@free$(echo .)fr \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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