On Sun, 17 Feb 2002, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Bruce Evans writes:
> >> This occurs both with and without the gettimeofday Giant-removal patch, so
> >> I am fairly sure it has nothing to do with any of my current work.  This is
> >> running -current on a DELL2550 (2xCPUs), compiled with the SMP option.
> The Gian removal doesn't come anywhere near this.

Yes it did.  There were Giants in the path for all syscalls.

> >The fact that the timecounter usually goes backwards by about 0.68 seconds
> >is probably significant, but I can't quite explain it.
> >>     acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> Well:
>       2^32 / 3579545 = 1199.86 seconds.
>       2^24 / 3579545 =    4.68 seconds.
> So even assuming that ACPI reported a wrong width, four seconds should
> still be enough to prevent a wraparound even though we cycle through
> the timecounter ring in one second.

No, there is only one seconds worth of of wraparaond, because recent
changes annulled the slightly less recent fixes for loss of nanoseconds
above the first 10^9 of them.  Previously, the multiplication corresponding
to the one in binuptime() overflowed at 2^32 nsec.  Now it overflows
at 2^64 in units of 2^-64 seconds.

> >I just wrote the following fix for some of the overflow problems.
> It is true that if a process is not running for arbitrary long time
> the timecounter may be modified underneat it, and bruce's patch is
> actually a pretty elegant solution for that case.  By all means
> try it.

Thanks :-).  In other mail you said "it pessimize the timecounters
elegant lockless design a fair bit".  Here the fair bit only applies
to the elegance.  The pessimization at runtime is tiny.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to