>>>>> On Fri, 03 Mar 2006 12:17:28 -0800, john stultz <[email protected]> said:
john> I'm not opposed to queuing it up as it seems like a logical
john> cleanup. I'd be fine with it going in before my patch, however
john> it still needs to address i386 lost tick compensation. I worry
john> that addressing that issue before my patchset (which makes the
john> lost tick compensation unnecessary) might be a bit more
john> complex. I think it would be easier going in after my patch. I
john> do think the barrier fix (with a comment) is a good short term
john> fix.
john> Atsushi: Your thoughts?
I agree. I missed i386 lost tick case and it seems more complex than
x86_64 case. Your patchset looks to make this cleanup very easy.
Then, here is an updated barrier fix patch.
Add an optimization barrier to prevent prefetching jiffies before
incrementing jiffies_64.
Signed-off-by: Atsushi Nemoto <[email protected]>
diff --git a/kernel/timer.c b/kernel/timer.c
index fc6646f..decd19e 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -925,6 +925,8 @@ static inline void update_times(void)
void do_timer(struct pt_regs *regs)
{
jiffies_64++;
+ /* prevent loading jiffies before storing new jiffies_64 value. */
+ barrier();
update_times();
softlockup_tick(regs);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
