From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Zachary Amsden <zach@vmware.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
george@mvista.com, Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] Fix a NO_IDLE_HZ timer bug
Date: Fri, 19 May 2006 11:26:04 +0200 [thread overview]
Message-ID: <1148030764.5350.8.camel@localhost> (raw)
In-Reply-To: <446CDDAE.1070908@vmware.com>
On Thu, 2006-05-18 at 13:48 -0700, Zachary Amsden wrote:
> It also looks like s390 has another bug. When compiling the 32-bit
> kernel, doesn't this computation overflow:
>
> arch/s390/kernel/time.c, stop_hz_timer:274
>
> /*
> * This cpu is going really idle. Set up the clock comparator
> * for the next event.
> */
> next = next_timer_interrupt();
> do {
> seq = read_seqbegin_irqsave(&xtime_lock, flags);
> timer = (__u64)(next - jiffies) + jiffies_64;
> } while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
>
>
> Since jiffies can advance between next_timer_interrupt and the read
> under xtime lock, next-jiffies could be negative. I would think you
> want to cast that to signed long instead of __u64, but I'm not totally
> qualified to talk about s390.
Seems like you are qualified to talk about s390 in this case. The
extension of (next - jiffies) to a 64 bit value needs to be done as a
signed extension, follow by a cast to u64. Blech. I think to cast next
and jiffies to u64 before subtracting them is cleaner. It takes a few
more cycles because we now do two 64 bit adds/subtracts but the code is
used for going idle so it doesn't matter. Patch attached, thanks Zach.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
--
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
[patch] s390: next_timer_interrupt overflow in stop_hz_timer.
The 32 bit unsigned substraction (next - jiffies) in stop_hz_timer
can overflow if jiffies gets advanced between next_timer_interrupt
and the read under the xtime lock. The cast to a u64 then results
in a large value which causes the cpu to wait too long.
Fix this by casting next and jiffies independently to u64 before
subtracting them.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/kernel/time.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -urpN linux-2.6/arch/s390/kernel/time.c linux-2.6-patched/arch/s390/kernel/time.c
--- linux-2.6/arch/s390/kernel/time.c 2006-05-16 09:44:29.000000000 +0200
+++ linux-2.6-patched/arch/s390/kernel/time.c 2006-05-19 11:04:04.000000000 +0200
@@ -272,7 +272,7 @@ static inline void stop_hz_timer(void)
next = next_timer_interrupt();
do {
seq = read_seqbegin_irqsave(&xtime_lock, flags);
- timer = (__u64)(next - jiffies) + jiffies_64;
+ timer = (__u64 next) - (__u64 jiffies) + jiffies_64;
} while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
todval = -1ULL;
/* Be careful about overflows. */
prev parent reply other threads:[~2006-05-19 9:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-18 20:48 [PATCH] Fix a NO_IDLE_HZ timer bug Zachary Amsden
2006-05-18 20:48 ` Zachary Amsden
2006-05-19 9:26 ` Martin Schwidefsky [this message]
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=1148030764.5350.8.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=akpm@osdl.org \
--cc=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
--cc=zach@vmware.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.