lkml.org 
[lkml]   [2017]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] Improving udelay/ndelay on platforms where that is possible
From
Date
On 15/11/2017 14:13, Russell King - ARM Linux wrote:

> udelay() needs to offer a consistent interface so that drivers know
> what to expect no matter what the implementation is. Making one
> implementation conform to your ideas while leaving the other
> implementations with other expectations is a recipe for bugs.
>
> If you really want to do this, fix the loops_per_jiffy implementation
> as well so that the consistency is maintained.

Hello Russell,

It seems to me that, when using DFS, there's a serious issue with loop-based
delays. (IIRC, it was you who pointed this out a few years ago.)

If I'm reading arch/arm/kernel/smp.c correctly, loops_per_jiffy is scaled
when the frequency changes.

But arch/arm/lib/delay-loop.S starts by loading the current value of
loops_per_jiffy, computes the number of times to loop, and then loops.
If the frequency increases when the core is in __loop_delay, the
delay will be much shorter than requested.

Is this a correct assessment of the situation?

(BTW, does arch/arm/lib/delay-loop.S load the per_cpu loops_per_jiffy
or the system-wide variable?)

Should loop-based delays be disabled when CPUFREQ is enabled?

Regards.

\
 
 \ /
  Last update: 2017-11-17 17:17    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog