[lkml]   [1999]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: gettimeofday non-monotonic on 2.2.7 SMP
On Mon, 17 May 1999, dave madden wrote:

>with max [i.e. maximum clock decrement detected] going up to
>5000-10000 (5-10ms) when I'm writing a CD or scrolling a Netscape

I should have fixed all gettimeofday SMP races in the late 2.1.x stage. I
also did quite testing also for get_fast_time retvail from irq handlers at
such time.

The only thing that may cause gettimeofday to return not monotone values
can be a missed timer irq or otherwise not synchornized tsc with SMP

If you miss a timer irq handler then gettimeoffset will follow you with
right values. Then when the next irq handler will happens you'll get a
wrong value since gettimeofsset will restart from 0 and you missed an irq.
You should get delta of the order of 100msec though.

To know if your problem is this one grab one of my andrea patches from:

and tell me if you can reproduce (you'll find andrea-patches for both
2.2.x and 2.3.x kernel).

In my patch I implemented a recover_lost_ticks mechanizm that will detect
a lost timer interrupt and will update xtime to take care of the lost irq.
This will only work with TSC enabled, if you don't have the i386 TSC you
will continue to lose time over the time ;) and gettimeofday can't be
monotone in presence of a lost tick.

If the problem is a lost tick over the time then my TSC code should tell
you also which is the piece of code that masked irqs on all cpus for a so
long time, so you can optimize it.


Andrea Arcangeli

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.043 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site