On Mon, 2007-07-16 at 14:33 -0700, Luck, Tony wrote:
On the subject of whether to push into 2.6.23 or cook in -mm until
2.6.24 ... I'm not sure how much benefit we'd get from the delay.
Anyone want to stand up and be counted as running serious testing
on -mm kernels on ia64? I fear that the
john stultz wrote:
Since gtod_lock.sequence will not tell us whether xtime is updated
(or going to be updated) while in this window, the result may be wrong...
So w/ x86_64, we've split the xtime_lock and get vgtod_lock, so that
only when the vsyscall page is being updated do we hold a write
Hi:
Thanks for the review.
Hidetoshi Seto wrote: [Tue Jul 17 2007, 06:55:47AM EDT]
Bob Picco wrote:
@@ -214,61 +209,56 @@ ENTRY(fsys_gettimeofday)
:
movl r27 = xtime
:
.time_redo:
-.pred.rel.mutex p8,p9,p10
-ld4.acq r28 = [r29] // xtime_lock.sequence. Must come first
On Tue, 2007-07-17 at 18:31 -0400, Bob Picco wrote:
Hi:
Thanks for the review.
Hidetoshi Seto wrote: [Tue Jul 17 2007, 06:55:47AM EDT]
Bob Picco wrote:
@@ -214,61 +209,56 @@ ENTRY(fsys_gettimeofday)
:
movl r27 = xtime
:
.time_redo:
- .pred.rel.mutex p8,p9,p10
- ld4.acq
Half a dozen whines from GIT about whitespace (irrelevent
paces followed by a TAB). Here are the lines:
+ /* Sort out mult/shift values: */
+ clocksource_register(clocksource_itc);
+#definewrite_counter(V, MC)writel(V, MC)
+ hpet_mctr = (void
