From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Doug Anderson <dianders@chromium.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Will Deacon <will.deacon@arm.com>,
John Stultz <john.stultz@linaro.org>,
David Riley <davidriley@chromium.org>,
"olof@lixom.net" <olof@lixom.net>,
Sonny Rao <sonnyrao@chromium.org>,
Richard Zhao <richard.zhao@linaro.org>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Shawn Guo <shawn.guo@linaro.org>,
Stephen Boyd <sboyd@codeaurora.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Stephen Warren <swarren@nvidia.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: Don't ever downscale loops_per_jiffy in SMP systems#
Date: Fri, 9 May 2014 10:18:24 +0100 [thread overview]
Message-ID: <20140509091824.GL3693@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.11.1405082058130.980@knanqh.ubzr>
On Thu, May 08, 2014 at 09:37:15PM -0400, Nicolas Pitre wrote:
> On Thu, 8 May 2014, Russell King - ARM Linux wrote:
>
> > If you're in a preempt or SMP environment, provide a timer for udelay().
> > IF you're in an environment with IRQs which can take a long time, use
> > a timer for udelay(). If you're in an environment where the CPU clock
> > can change unexpectedly, use a timer for udelay().
>
> Longer delays are normally not a problem. If they are, then simply
> disabling IRQs may solve it if absolutely required. With much shorter
> delays than expected this is another story.
>
> What about the following:
>
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 7c4fada440..10030cc5a0 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -682,6 +682,15 @@ static int cpufreq_callback(struct notifier_block *nb,
> cpufreq_scale(per_cpu(l_p_j_ref, cpu),
> per_cpu(l_p_j_ref_freq, cpu),
> freq->new);
> + /*
> + * Another CPU might have called udelay() just before LPJ
> + * and a shared CPU clock is increased. That other CPU still
> + * looping on the old LPJ value would return significantly
> + * sooner than expected. The actual fix is to provide a
> + * timer based udelay() implementation instead.
> + */
> + if (freq->old < freq->new)
> + pr_warn_once("*** udelay() on SMP is racy and may be much shorter than expected ***\n");
> }
> return NOTIFY_OK;
> }
No, because you're assuming this is just a SMP problem. What about
preempt, where you could preempt away from a udelay loop to change
the CPU frequency, and then back again, possibly resulting in the
CPU clock rate increasing and maybe a shorter delay if the switch
from-change-clock-and-back is fast enough? Remember that udelay()
can be used for up to 2ms delays.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
next prev parent reply other threads:[~2014-05-09 9:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 23:23 [PATCH] ARM: Don't ever downscale loops_per_jiffy in SMP systems Doug Anderson
2014-05-08 10:41 ` Viresh Kumar
2014-05-08 15:25 ` Doug Anderson
2014-05-08 16:04 ` Nicolas Pitre
2014-05-08 16:41 ` Doug Anderson
2014-05-08 17:43 ` Nicolas Pitre
2014-05-08 18:06 ` Doug Anderson
2014-05-08 19:59 ` Nicolas Pitre
2014-05-08 20:55 ` Russell King - ARM Linux
2014-05-09 0:02 ` Doug Anderson
2014-05-09 0:23 ` Russell King - ARM Linux
2014-05-09 4:41 ` Doug Anderson
2014-05-08 19:22 ` Russell King - ARM Linux
2014-05-08 20:12 ` Nicolas Pitre
2014-05-08 20:39 ` John Stultz
2014-05-08 20:52 ` Russell King - ARM Linux
2014-05-09 1:37 ` Nicolas Pitre
2014-05-09 4:43 ` Doug Anderson
2014-05-09 9:18 ` Russell King - ARM Linux [this message]
2014-05-09 18:00 ` [PATCH] ARM: Don't ever downscale loops_per_jiffy in SMP systems# Nicolas Pitre
2014-05-09 18:22 ` Russell King - ARM Linux
2014-05-09 21:05 ` Nicolas Pitre
2014-05-12 23:51 ` Doug Anderson
2014-05-13 21:50 ` Doug Anderson
2014-05-13 22:15 ` Stephen Warren
2014-05-13 23:15 ` Nicolas Pitre
2014-05-13 23:29 ` Nicolas Pitre
2014-05-13 23:36 ` Russell King - ARM Linux
2014-05-14 21:42 ` Doug Anderson
2014-05-15 6:12 ` Viresh Kumar
2014-05-09 9:25 ` [PATCH] ARM: Don't ever downscale loops_per_jiffy in SMP systems Viresh Kumar
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=20140509091824.GL3693@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=davidriley@chromium.org \
--cc=dianders@chromium.org \
--cc=john.stultz@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=nicolas.pitre@linaro.org \
--cc=olof@lixom.net \
--cc=paul.gortmaker@windriver.com \
--cc=richard.zhao@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=santosh.shilimkar@ti.com \
--cc=sboyd@codeaurora.org \
--cc=shawn.guo@linaro.org \
--cc=sonnyrao@chromium.org \
--cc=swarren@nvidia.com \
--cc=viresh.kumar@linaro.org \
--cc=will.deacon@arm.com \
/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).