Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)

[Ingo Molnar]

* Andrea Arcangeli <andrea@xxxxxxx> wrote:

> > what do you mean by delayed?
> 
> if the timer softirq doesn't run and wall_jiffies doesn't increase, we
> won't be able to account for it, so time() will return a time in the
> past, it will potentially go backwards precisely 1/HZ seconds every
> tick that isn't executing the timer softirq. [...]

we agree that this all is not an issue, but the reasons are different 
from what you describe.

wall_jiffies (and, more importantly, xtime.tv_sec - which is the clock
source used by sys_time()) is updated from hardirq context - so softirq
delay cannot impact it.

gettimeofday() and time() are unsynchronized clocks, and time() will
almost always return a time less than the current time - due to rounding
down.

in the moments where there's a timer IRQ pending (or the timer IRQ's
time update effect is delayed eg. due to contention on xtime_lock)
gettimeofday() can estimate the current time past the timer tick, at
which moment the inaccuracy of time() can be briefly higher than 1
second. (in most cases it should be 1 second + delta)

> [...] I tend to agree for a 1sec resultion that's not a big deal
> though if you run:
> 
> 	gettimeofday()
> 	time()
> 
> gettimeofday may say the time of the day is 17:39:10 and time may tell
> 17:39:09

nobody should rely on gettimeofday() and time() being synchronized on
the second level. Typically the delta will be [0 ... 0.999999 ] seconds,
occasionally it can get larger.

and this has nothing to do with using vsyscalls and it can already
happen. xtime.tv_sec is used without any synchronization so even if
xtime were synchronized with gettimeofday() [eg. by do_gettimeofday()
noticing that xtime.tv_sec needs an update] - the access is not
serialized on SMP.

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