From: Phil Carmody <ext-phil.2.carmody@nokia.com>
To: mingo@elte.hu, gregkh@suse.de, linux@arm.linux.org.uk, tony@atomide.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, travis@sgi.com,
akataria@vmware.com
Subject: [PATCH 3/4] calibrate: retry with wider bounds when converge seems to fail
Date: Tue, 28 Sep 2010 13:44:59 +0300 [thread overview]
Message-ID: <1285670700-11099-4-git-send-email-ext-phil.2.carmody@nokia.com> (raw)
In-Reply-To: <1285670700-11099-3-git-send-email-ext-phil.2.carmody@nokia.com>
Systems with unmaskable interrupts such as SMIs may massively underestimate
loops_per_jiffy, and fail to converge anywhere near the real value. A case
seen on x86_64 was an initial estimate of 256<<12, which converged to 511<<12
where the real value should have been over 630<<12. This admitedly requires
bypassing the TSC calibration (lpj_fine), and a failure to settle in the
direct calibration too, but is physically possible. This failure does not
depend on my previous calibration optimisation, but by luck is easy to fix
with the optimisation in place with a trivial retry loop.
In the context of the optimised converging method, as we can no longer trust
the starting estimate, enlarge the search bounds exponentially so that the
number of retries is logarithmically bounded.
---
init/calibrate.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/init/calibrate.c b/init/calibrate.c
index 7315c9a..5a734de 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -122,7 +122,7 @@ static unsigned long __cpuinit calibrate_delay_direct(void) {return 0;}
static unsigned long __cpuinit calibrate_delay_converge(void)
{
/* First stage - slowly accelerate to find initial bounds */
- unsigned long lpj, ticks, loopadd, chop_limit;
+ unsigned long lpj, lpj_base, ticks, loopadd, loopadd_base, chop_limit;
int trials = 0, band = 0, trial_in_band = 0;
lpj = (1<<12);
@@ -146,14 +146,18 @@ static unsigned long __cpuinit calibrate_delay_converge(void)
* the largest likely undershoot. This defines our chop bounds.
*/
trials -= band;
- loopadd = lpj * band;
- lpj *= trials;
- chop_limit = lpj >> (LPS_PREC + 1);
+ loopadd_base = lpj * band;
+ lpj_base = lpj * trials;
+
+recalibrate:
+ lpj = lpj_base;
+ loopadd = loopadd_base;
/*
* Do a binary approximation to get lpj set to
* equal one clock (up to LPS_PREC bits)
*/
+ chop_limit = lpj >> LPS_PREC;
while (loopadd > chop_limit) {
lpj += loopadd;
ticks = jiffies;
@@ -165,6 +169,16 @@ static unsigned long __cpuinit calibrate_delay_converge(void)
lpj -= loopadd;
loopadd >>= 1;
}
+ /*
+ * If we incremented every single time possible, presume we've
+ * massively underestimated initially, and retry with a higher
+ * start, and larger range. (Only seen on x86_64.)
+ */
+ if (lpj + loopadd * 2 == lpj_base + loopadd_base * 2) {
+ lpj_base = lpj;
+ loopadd_base <<= 2;
+ goto recalibrate;
+ }
return lpj;
}
--
1.7.2.rc1.37.gf8c40
next prev parent reply other threads:[~2010-09-28 10:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 10:44 [PATCHv2 0/4] Improve fallback LPJ calculation Phil Carmody
2010-09-28 10:44 ` [PATCH 1/4] calibrate: extract fall-back calculation into own helper Phil Carmody
2010-09-28 10:44 ` [PATCH 2/4] calibrate: home in on correct lpj value more quickly Phil Carmody
2010-09-28 10:44 ` Phil Carmody [this message]
2010-09-28 10:45 ` [PATCH 4/4] DO NOT INTEGRATE: test-only timing Phil Carmody
2011-03-10 14:48 [PATCHv3 0/4] Improve fallback LPJ calculation Phil Carmody
2011-03-10 14:48 ` [PATCH 1/4] calibrate: extract fall-back calculation into own helper Phil Carmody
2011-03-10 14:48 ` [PATCH 2/4] calibrate: home in on correct lpj value more quickly Phil Carmody
2011-03-10 14:48 ` [PATCH 3/4] calibrate: retry with wider bounds when converge seems to fail Phil Carmody
2011-03-11 23:27 ` Andrew Morton
2011-03-12 2:10 ` Phil Carmody
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=1285670700-11099-4-git-send-email-ext-phil.2.carmody@nokia.com \
--to=ext-phil.2.carmody@nokia.com \
--cc=akataria@vmware.com \
--cc=gregkh@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@elte.hu \
--cc=tony@atomide.com \
--cc=travis@sgi.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
all inboxes | Powered by JetHome®