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.
From 1584245584916467099@xxx Thu Nov 16 17:45:25 +0000 2017
X-GM-THRID: 1582790467810046578
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Thu, Nov 16, 2017 at 04:26:51PM +0100, Marc Gonzalez wrote:
> 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?
Absolutely correct, and it's something that people are aware of, and
have already catered for while writing their drivers.
> (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?
What about platforms (and there are those in the kernel today) which
have CPUFREQ enabled and also have no timer based delay registered?
These rely on using the delay loop mechanism today.
What this means is you can't just "turn off" loop-based delays just
because CPUFREQ is enabled, because that's going to cause regressions.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
From 1584168277148459169@xxx Wed Nov 15 21:16:38 +0000 2017
X-GM-THRID: 1582790467810046578
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread