From: James Bottomley <James.Bottomley@steeleye.com>
To: Andrew Morton <akpm@osdl.org>, johnstultz@us.ibm.com
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH] fix get_jiffies_64 to work on voyager
Date: 06 Jan 2004 10:04:07 -0600 [thread overview]
Message-ID: <1073405053.2047.28.camel@mulgrave> (raw)
This patch
ChangeSet@1.1534.5.2, 2003-12-30 15:40:23-08:00, akpm@osdl.org
[PATCH] ia32 jiffy wrapping fixes
Causes the voyager boot to hang. The problem is this change:
--- a/arch/i386/kernel/timers/timer_tsc.c Tue Jan 6 09:57:34 2004
+++ b/arch/i386/kernel/timers/timer_tsc.c Tue Jan 6 09:57:34 2004
@@ -141,7 +140,7 @@
#ifndef CONFIG_NUMA
if (!use_tsc)
#endif
- return (unsigned long long)jiffies * (1000000000 / HZ);
+ return (unsigned long long)get_jiffies_64() *
(1000000000 / HZ);
Apart from the fact (that I've whined about before) that this
sched_clock() function should be one of the timer function pointers, so
there isn't this CONFIG_NUMA dependence (unless I can also add a
CONFIG_X86_VOYAGER dependence to it as well), the problem seems to be
some type of bad resonance between the jiffies_64 update and the
xtime_lock in get_jiffies_64(). I think this may indicate that HZ needs
to be reduced to 100 on voyager; however, there is also no need to get
the xtime sequence lock every time we do a jiffies_64 read, since the
only unstable time is when we may be updating both halves of it
non-atomically. Thus, we only need the sequence lock when the bottom
half is zero. This should improve the fast path of get_jiffies_64() for
all x86 arch's.
James
===== kernel/time.c 1.18 vs edited =====
--- 1.18/kernel/time.c Wed Oct 22 00:09:54 2003
+++ edited/kernel/time.c Tue Jan 6 09:20:38 2004
@@ -422,13 +422,20 @@
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void)
{
- unsigned long seq;
- u64 ret;
+ u64 ret = jiffies_64;
- do {
- seq = read_seqbegin(&xtime_lock);
+ /* We only have read problems when the lower 32 bits are zero
+ * indicating that we may be in the process of updating the upper
+ * 32 bits */
+ while (unlikely((jiffies_64 & 0xffffffffULL) == 0)) {
+ unsigned long seq = read_seqbegin(&xtime_lock);
+
+ rmb();
ret = jiffies_64;
- } while (read_seqretry(&xtime_lock, seq));
+ rmb();
+ if(!read_seqretry(&xtime_lock, seq))
+ break;
+ }
return ret;
}
next reply other threads:[~2004-01-06 16:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-06 16:04 James Bottomley [this message]
2004-01-06 16:19 ` [PATCH] fix get_jiffies_64 to work on voyager Andrew Morton
2004-01-06 16:26 ` James Bottomley
2004-01-06 17:05 ` Andrew Morton
2004-01-06 18:53 ` James Bottomley
2004-01-06 16:29 ` Linus Torvalds
2004-01-06 17:05 ` Andrew Morton
2004-01-06 17:11 ` Tim Schmielau
2004-01-06 17:22 ` Andrew Morton
2004-01-06 17:37 ` Tim Schmielau
2004-01-06 18:02 ` Linus Torvalds
2004-01-06 16:30 ` Tim Schmielau
2004-01-06 16:26 ` Linus Torvalds
2004-01-06 18:29 ` Paulo Marques
2004-01-06 18:46 ` Linus Torvalds
2004-01-06 19:04 ` Paulo Marques
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=1073405053.2047.28.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=johnstultz@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
/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.