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

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Mar 05, 2004 at 05:49:02PM +0100, Ingo Molnar wrote:
> 
> * Andi Kleen <ak@suse.de> wrote:
> 
> > > > [...] Only drawback is that if a timer tick is delayed for too long it
> > > > won't fix that, but I guess that's reasonable for a 1s resolution.
> > > 
> > > what do you mean by delayed?
> > 
> > Normal gettimeofday can "fix" lost timer ticks because it computes the
> > true offset to the last timer interrupt using the TSC or other means.
> > xtime is always the last tick without any correction. If it got
> > delayed too much the result will be out of date.
> 
> yeah - i doubt the softirq delay is a real issue.

Do you think it's more likely the irq is lost? I think it's more likely
the softirq takes more than 1msec than the irq is lost. If softirq takes
more than 1msec we don't necessairly need to fix that, the timer code is
designed to handle that case properly and the softirq is the place where
to do the bulk of the work, if irq is lost we definitely need to fix
that.

Anyways either ways time may go backwards w.r.t. gettimeofday.

I'm not saying it's a real issue though.