On Wed, 2007-07-25 at 11:49 -0700, Daniel Walker wrote:
>
> > Also, this kernel boots up EXTREMELY slow. once it is booted, the
> timer
> > soft-irqs on both cpus run (according to top) at about 4% of the CPU
> > constantly. X is very jerky, I assume because of the soft-irqs
> running
> > so much...?
>
On my 8 core, I consistently get a watchdog after applying the following
patch:
After the watchdog pops, things go back to normal speed.
Date: Tue, 17 Jul 2007 17:49:34 +0200
From: Ingo Molnar <[EMAIL PROTECTED]>
To: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Andrew Morton <[EMAIL PROTECTED]>, Linus Torvalds
<[EMAIL PROTECTED]>, [EMAIL PROTECTED], Greg KH <[EMAIL PROTECTED]>, Chris
Wright <[EMAIL PROTECTED]>
Subject: [patch] fix the softlockup watchdog to actually work
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.14 (2007-02-12)
Received-SPF: softfail (mx3: transitioning domain of elte.hu does not
designate 157.181.1.14 as permitted sender) client-ip=157.181.1.14;
[EMAIL PROTECTED]; helo=elvis.elte.hu;
X-ELTE-VirusStatus: clean
X-ELTE-SpamScore: -1.0
X-ELTE-SpamLevel:
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0
X-ELTE-SpamCheck-Details: score=-1.0 required=5.9 tests=BAYES_00
autolearn=no SpamAssassin version=3.0.3 -1.0 BAYES_00
BODY:
Bayesian spam probability is 0 to 1% [score: 0.0000]
Sender: [EMAIL PROTECTED]
Precedence: bulk
X-Mailing-List: [EMAIL PROTECTED]
X-Evolution-Source: imap://[EMAIL PROTECTED]/
Content-Transfer-Encoding: 8bit
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > Subject: softlockup: fix Xen bogosity
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> >
> > this Xen related commit:
> >
>
> Well, not just Xen. It relates to any virtual environment: kvm,
> lguest, vmi, xen... (Not that they all implement a measure of
> unstolen time.)
>
> How about a more descriptive patch title, along the lines of
> "softlockup watchdog: fix rate limiting"?
uhm, the problem was that it did not work _at all_, not something about
'rate limiting'. Yes, i got quite a bit grumpy when i found this,
because you completely broke the softlockup watchdog via a pretty
intrusive commit and you apparently didnt even do a minimal check
whether its functionality was preserved! Updated patch for Andrew/Linus
and for -stable attached.
Ingo
----------------------------->
Subject: fix the softlockup watchdog to actually work
From: Ingo Molnar <[EMAIL PROTECTED]>
this Xen related commit:
commit 966812dc98e6a7fcdf759cbfa0efab77500a8868
Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Date: Tue May 8 00:28:02 2007 -0700
Ignore stolen time in the softlockup watchdog
broke the softlockup watchdog to never report any lockups. (!)
print_timestamp defaults to 0, this makes the following condition
always true:
if (print_timestamp < (touch_timestamp + 1) ||
and we'll in essence never report soft lockups.
apparently the functionality of the soft lockup watchdog was never
actually tested with that patch applied ...
[this is -stable material too.]
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/softlockup.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux/kernel/softlockup.c
===================================================================
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -79,10 +79,11 @@ void softlockup_tick(void)
print_timestamp = per_cpu(print_timestamp, this_cpu);
/* report at most once a second */
- if (print_timestamp < (touch_timestamp + 1) ||
- did_panic ||
- !per_cpu(watchdog_task, this_cpu))
+ if ((print_timestamp >= touch_timestamp &&
+ print_timestamp < (touch_timestamp + 1)) ||
+ did_panic || !per_cpu(watchdog_task, this_cpu)) {
return;
+ }
/* do not print during early bootup: */
if (unlikely(system_state != SYSTEM_RUNNING)) {
-
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
