Messages in this thread | | | Date | Sat, 17 Oct 1998 07:53:58 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft] |
| |
On Fri, 16 Oct 1998, Andrea Arcangeli wrote:
> It' s not. I catched very big problems in the do_fast_gettimeoffset() at > least. In such function the jiffies static initialization change cause > problems (just fixed also in other arch). > > Seems that such function cause a div_by_zero fault if run when jiffies == > 0 if I understand well this: > > (divl %2) == (dx:ax / %2) > > Unfortunately I had not time to understand what do_fast_gettimeoffset() > does, I was going to work on it now.
Unfortunately I had time and reason to figure out what it does ;-< It tries to do the following: assume that we last time we got a timer interrupt we were at J jiffies from the boot and N TSC ticks from the same event. We are called between two timer interrupts and want to figure out how many time passed since the last one. Fine, just read the current TSC value (say it, N1) and try the following: ((N1-N)*J/N)*(time_units_per_jiffie) Since J/N ratio changes only on timer interrupts we can try to push division out of the main branch. The problem occurs when J/N (actually J*2^32/N; trivial scaling) goes too high. It _can_ happen on braindead processors that don't increase TSC when they are halted (in theory TSC should be increased on each CLOCK signal). Kernel doesn't like the idea of being run on sub-MHz processor ;-/ You can fix it by checking for too low values of N (and assuming that in this case we should return 1/100sec), but actually we shouldn't use do_fast_gettimeofday() on such processors. It's pretty spectacular: write a trivial program that reads /dev/kmem and computes the ratio. You'll see how it drops when system is inactive. Usually you start with something around the actual clock rate of your processor (scaled) due to the activity on the boottime. After a while it decreases. When it reaches 1000 (IIRC) programs doing gettimeofday() begin to oops. wc </dev/hda "fixes" the situation...
- 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/
| |