Re: problems with do_slow_gettimeoffset()

From: Boris Okun (bokun@home.com)
Date: Mon Apr 03 2000 - 15:51:20 EST


Jason Sodergren wrote:
>
> On Fri, 31 Mar 2000, Boris Okun wrote:
>
> > I think the easier and faster way to do the underflow detection would be
> > to
> > compare offset with delay_at_last_interrupt which we save in
> > timer_interrupt() ( we currently save it only if tsc is enabled so we'll
> > have to move it out of if(use_tsc){} ). Then just put
> >
> > if (count < delay_at_last_interrupt ) count += TICK_SIZE;
>
> Problem I see with that is that we still have a situation where a
> pending timer interrupt is not recognized:
>
> - IRQ0 ISR sets delay_at_last_interrupt based on counter.
> If interrupts were not disabled when IRQ0 occurs, then
> delay_at_last_interrupt is quite close to LATCH.
>
> - Another interrupt occurs/ISR is entered/interrupts disabled
> slightly before next IRQ0.
>
> - IRQ0 occurs with interrupts disabled. IRQ0 is pending; 8254 counter
> has underflowed and reset to LATCH.
>
> - Interrupt disabled ISR code is still executing for some time after IRQ0
> > time represented by (LATCH - delay_at_last_interrupt).
>
> - do_slowgettimeoffset() is called. delay_at_last_interrupt logic
> does not recognize underflow, since read value of counter is not
> > delay_at_last_interrupt.

Yes, I see the problem.

>
> It seems that the interrupt pending bit has to be examined in order
> to avoid mistakes that could arise from basing an underflow detection
> solely on values of a previous read of the counter...

Now, I see another problem on SMP with do_slowgettimeoffset(): suppose
timer irq happened during gettimeofday(), but before we latch the
counter. If interrupts on another processor are enabled, then there is
no pending interrupt and the other prcessor spins on xtime_lock, so
lost_ticks are not updated either. So i don't see how we can detect this
at all. Perhaps, we should make lost_ticks atomic and take it out of
xtime_locked region?

Boris

-
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/



This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:10 EST