On Sun, 17 Feb 2002, Matthew Dillon wrote:
> Ok, I've looked at the code more carefully and I understand how this
> works now. However, it is not enough in an SMP environment. You
> need a generation count in the timecounter structure and you also need
> a synchronization point
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 DELL255
Ok, I've looked at the code more carefully and I understand how this
works now. However, it is not enough in an SMP environment. You
need a generation count in the timecounter structure and you also need
a synchronization point when you switch time counters or a process
runni
:I just wrote the following fix for some of the overflow problems.
I don't understand how this code is supposed to handle overflows.
You seem only to be checking to see if the master timecounter has
changed to a different type.
-Matt
On Sat, 16 Feb 2002, Matthew Dillon wrote:
> Testing with a 'make -j 10 buildworld' on a -current box I am getting
> regular:
>
> microuptime() went backwards (146.826785 -> 146.156715)
> microuptime() went backwards (146.826782 -> 146.228636)
> ...
> microuptime() went backwards
