From: Peter Zijlstra <peterz@infradead.org>
To: Terry Loftin <terry.loftin@hp.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Bob Montgomery <bob.montgomery@hp.com>,
John Stultz <johnstul@us.ibm.com>
Subject: Re: [PATCH 2/2] sched: Fix "divide error: 0000" in find_busiest_group
Date: Wed, 20 Jul 2011 00:33:15 +0200 [thread overview]
Message-ID: <1311114795.2617.10.camel@laptop> (raw)
In-Reply-To: <4E26036E.1070903@hp.com>
On Tue, 2011-07-19 at 16:21 -0600, Terry Loftin wrote:
> > So you're running on a platform (unspecified) where we use a raw
> > sched_clock() that is buggy. Again, you're fixing symptoms not causes.
> >
> This x86_64. This is the actual cause, unless the rq->clock
> value should never roll, in which case, the clock roll is the
> actual cause and you can disregard these patches.
Its supposed to roll over on the full 64bit, and I think x86_64 only
suffers this if you have sched_clock_stable set to 1.
So I think the correct fix is disabling that logic for now. John Stultz
was working on some patches to fix __cycles_2_ns().
Something like the below perhaps.
---
arch/x86/kernel/cpu/intel.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 1edf5ba..dba0482 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -91,8 +91,6 @@ static void __cpuinit early_init_intel(struct cpuinfo_x86 *c)
if (c->x86_power & (1 << 8)) {
set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
- if (!check_tsc_unstable())
- sched_clock_stable = 1;
}
/*
next prev parent reply other threads:[~2011-07-19 22:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 20:58 [PATCH 2/2] sched: Fix "divide error: 0000" in find_busiest_group Terry Loftin
2011-07-19 21:18 ` Peter Zijlstra
2011-07-19 22:21 ` Terry Loftin
2011-07-19 22:33 ` Peter Zijlstra [this message]
2011-07-19 22:39 ` Terry Loftin
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=1311114795.2617.10.camel@laptop \
--to=peterz@infradead.org \
--cc=bob.montgomery@hp.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=terry.loftin@hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.