lkml.org 
[lkml]   [1999]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday non-monotonic on 2.2.7 SMP
 =>From: Andrea Arcangeli <andrea@suse.de>
=>...
=>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
=>hardware.
=>
=>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:
=>
=> ftp://e-mind.com/pub/andrea/kernel/
=>
=>and tell me if you can reproduce (you'll find andrea-patches for both
=>2.2.x and 2.3.x kernel).

I built a new 2.3.3 kernel (Makefile still says 2.3.2...I guess
somebody forgot to update it?) with your patches. As you suspected:

May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from 080c1fb8
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from 40218baf
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from 40218ba8
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from 401c8360
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from 401c7fbe
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from c0107997
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from 401c82d6
May 19 21:33:46 vheissu kernel: recover_lost_timer: lost 1 tick from c0107997

c010795c T cpu_idle
c01079ac T sys_idle

I also got this "lost 429495 ticks" (!) from a previous kernel build,
but I don't have the System.map to go with it. I wish I knew what was
going on here; clearly, some signed calculation is returning a
negative number which is then being cast to unsigned. I think this is
the original problem I was having, with the clock jumping back & forth
4294 seconds (429495 ticks, right?)

May 19 21:24:09 vheissu kernel: recover_lost_timer: lost 429495 ticks from c0107997
May 19 21:24:09 vheissu kernel: recover_lost_timer: lost 2 ticks from c0107997
May 19 21:24:20 vheissu kernel: recover_lost_timer: lost 1 tick from c01f2ef7
May 19 21:24:20 vheissu kernel: recover_lost_timer: lost 1 tick from c0107997

=>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.

A lot of the ticks are lost from 0x40... is that userland? How can I
find out which process? (I suspect the X server: the easiest way to
lose ticks is to scroll a Netscape X window.) Can the server turn off
IRQs on both CPUs?

=>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.

Is there any way to force gettimeofday not to return an earlier time?
Of course, I want the clock to be as accurate as possible, but the
time decrements are causing more trouble than a simple slow or fast
clock would. I've modified do_gettimeofday so that it maintains the
latest time it ever returned, and won't return a time earlier than
this. (The remembered time is updated in do_settimeofday so that
clock adjustments will still take effect.) This seems to help, but do
you see any problems with it?

regards,
d.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site